The Berlin Group openFinance API Framework
Foundational course

Module 2: The Baseline - Core PSD2 Services (NextGenPSD2)

This module examines the three core services that were mandated by PSD2 and which form the foundation of the NextGenPSD2 framework. These services—AIS, PIS, and FCS—are now integrated as the compliance baseline within the broader openFinance API Framework.

Account Information Services (AIS)

The Account Information Service enables a licensed TPP, acting as an Account Information Service Provider (AISP), to retrieve payment account information on behalf of a PSU, provided the PSU has given their explicit consent. This service is the cornerstone of many fintech applications, such as personal finance management (PFM) tools that aggregate data from multiple bank accounts.

The key API calls for AIS are:

• GET /v1/accounts: This endpoint is used to retrieve a list of all payment accounts that the PSU has made accessible under a given consent.
• GET /v1/accounts/{accountId}/balances: Once an account is identified, this endpoint is used to fetch the current and available balances for that specific account.
• GET /v1/accounts/{accountId}/transactions: This endpoint retrieves a list of historical transactions for a specified account. The API supports pagination and filtering parameters, such as dateFrom and dateTo, to allow the TPP to request specific transaction periods.

Payment Initiation Services (PIS)

The Payment Initiation Service allows a licensed TPP, acting as a Payment Initiation Service Provider (PISP), to initiate a payment order from a PSU's account to a beneficiary. This service enables innovative payment solutions, such as direct account-to-account payments at e-commerce checkouts.

The framework is designed to be flexible and supports a wide range of payment products to cater to different market needs:

• Single Payments: Including standard SEPA Credit Transfers (SCT), SEPA Instant Credit Transfers (SCT Inst), and cross-border payments.
• Future-Dated and Periodic Payments: The API supports the initiation of payments to be executed on a future date and the setup of recurring payments (standing orders).
• Bulk Payments: The framework allows for the initiation of multiple payments in a single request, which is particularly useful for corporate use cases such as payroll processing.

The primary API calls for PIS include:

• POST /v1/{payment-service}/{payment-product}: This is the central endpoint for creating a new payment initiation resource. The payment-service and payment-product path parameters specify the type of payment (e.g., /v1/payments/sepa-credit-transfers).
• GET /v1/{payment-service}/{payment-product}/{paymentId}: Used to retrieve the current status of a previously initiated payment (e.g., Received, Accepted, Rejected, Executed).
• DELETE /v1/{payment-service}/{payment-product}/{paymentId}: Allows a TPP to request the cancellation of a payment that has not yet been executed by the ASPSP, such as a future-dated or recurring payment.

Confirmation on the Availability of Funds (FCS/CAF)

The Confirmation on the Availability of Funds service is a more specialised service designed for TPPs that issue card-based payment instruments (PIISPs). It allows the PIISP to send a simple request to the PSU's ASPSP to confirm whether sufficient funds are available on the account to cover a specific transaction amount at that moment. This check happens before the payment is authorised, helping to reduce the risk of declined transactions.

The service is intentionally lightweight. The key API call is:

• POST /v1/funds-confirmations: The request body contains the amount and currency of the transaction. The ASPSP's response is a simple boolean value: true if funds are available, or false if they are not. The service does not block or reserve the funds; it is purely an informational check.

Managing Access: The Consent Management Lifecycle

A fundamental principle underpinning all services is that no action can be taken without the PSU's explicit and informed consent. The framework's architecture reflects this by treating consent as a distinct, manageable resource, which enhances security and transparency for the user. Instead of bundling a data request with an implicit consent, the process is separated into two distinct steps. First, the TPP creates a consent resource that explicitly details the scope of the requested access (e.g., which accounts, what data, and for how long). Second, the PSU is asked to authorise that specific, well-defined consent object using an SCA flow.

This separation provides several benefits. It makes the PSU's permission granular and auditable. The PSU is not granting open-ended access but is authorising a very specific, time-limited request. This consent object can then be managed throughout its lifecycle independently of any data access, aligning with GDPR principles of user control and building trust in the ecosystem.

The API provides dedicated endpoints for managing the consent lifecycle:

• POST /v1/consents: A TPP uses this endpoint to create a new account information consent resource. The request body specifies the scope of the consent, such as which accounts are to be accessed (accounts, balances, transactions), how frequently the data can be accessed (frequencyPerDay), and the duration for which the consent is valid (validUntil).
• GET /v1/consents/{consentId}: This allows the TPP to retrieve the current status of a consent (e.g., received, valid, revokedByPsu, expired).
• DELETE /v1/consents/{consentId}: This endpoint is used by the TPP to delete a consent, effectively revoking its access to the PSU's data.