The Berlin Group openFinance API Framework
Foundational course

Module 3: Beyond Compliance - openFinance Premium Services

While the core PSD2 services provided the foundation for compliance, the true innovative potential of the Berlin Group's work lies in the openFinance premium services. These are voluntary, market-driven extensions that enable financial institutions to offer new value-added products and services, moving beyond regulatory obligations and into commercial opportunities.

Extended Account Information Services (AIS)

A significant limitation of PSD2 was its narrow focus on "payment accounts." The openFinance framework breaks down this silo by defining standardised API access for a broader range of financial products, enabling a truly holistic view of a customer's financial life.

The framework includes specific implementation guidelines for accessing non-payment accounts, including:

• Savings Accounts: Allowing for the retrieval of balances and transaction histories.
• Loan Accounts: Providing access to loan details, repayment schedules, and outstanding balances.
• Securities Accounts: Enabling the retrieval of portfolio holdings, positions, and transaction histories for investments.

These extended AIS capabilities are powerful enablers for new services. They allow for the creation of sophisticated Personal Finance Management (PFM) and Business Finance Management (BFM) tools, aggregated wealth management dashboards that combine banking and investment data. Additionally, they facilitate streamlined credit application processes where applicants can consent to share their full financial picture with a lender.

Extended Payment Initiation Services (PIS)

Extended PIS moves beyond simple credit transfers to introduce more advanced payment functionalities. These services were developed in response to market demand for more flexible, card-like features within the account-to-account payment space.

Examples of such premium services include:

• Reservation of Funds: A mechanism to temporarily block or earmark funds on a PSU's account for a future payment, similar to a pre-authorisation on a credit card.
• Pay by Loan: A service that allows a payment to be funded directly from a pre-approved credit line or loan product, rather than a current account.
• Payments with Document Handling: The ability to attach supplementary documents (like an invoice) to a payment initiation.

The technical details for these services are specified in the "Extended PIS Implementation Guidelines V2," which defines the necessary API endpoints and data structures to support these complex payment scenarios.

Request to Pay (RTP)

Request to Pay is a messaging functionality, not a payment instrument itself. It enables a payee (e.g., a merchant, utility company, or individual) to send a structured request for payment to a payer. The payer can then approve or reject this request, and an approval can trigger a standard payment initiation, such as a SEPA Instant Credit Transfer.

The Berlin Group's RTP specification provides the technical foundation for this interaction. The "RTP Implementation Guidelines" and "Operational Rules" define the API flows for the complete lifecycle:

• Sending the RTP from the payee to the payer.
• The payer receiving and reviewing the request.
• The payer responding with an acceptance or rejection.
• Linking the accepted RTP to a subsequent payment initiation via PIS.

Crucially, the Berlin Group's RTP standard is designed to be fully compatible with the pan-European SEPA Request-to-Pay (SRTP) scheme defined by the European Payments Council (EPC). This alignment ensures that implementations based on the Berlin Group standard can interoperate seamlessly within the broader European SRTP ecosystem.

The development of services like RTP and VOP highlights a significant evolution in the Berlin Group's role. It has moved beyond being a pure technical standardiser for regulatory compliance and has become a critical technical enabler for new, pan-European payment schemes. Schemes like the EPC's SRTP and VOP define the crucial business rules, liability frameworks, and operational procedures. However, a scheme cannot function without a technical implementation layer. Without a harmonised API standard, each participant would need to build bespoke integrations, leading to the very fragmentation and high costs that PSD2 APIs were meant to solve. By providing the standardised API specifications for these schemes, the Berlin Group acts as the technical backbone, supplying the common "rails" upon which the scheme "trains" can run. This symbiotic relationship, where the EPC defines the "rules of the road" and the Berlin Group provides the "standardised road signs," is essential for the successful launch and scalable adoption of new, innovative financial services across Europe.

Verification of Payee (VOP)

The Verification of Payee service is a direct technical response to a key requirement in the EU's Instant Payments Regulation (IPR). To combat fraud and misdirected payments, the IPR mandates that payment service providers must offer a service to payers to verify that the name of the beneficiary matches the provided IBAN before a payment is confirmed.

The Berlin Group's VOP specification provides a harmonised API for this check. The service allows the payer's PSP to send a request containing the payee's name and IBAN to the payee's PSP. The payee's PSP then performs the check against its own records and returns a standardised response, such as MATCH, NO_MATCH, or PARTIAL_MATCH.

The "Verification of Payee Implementation Guidelines" document defines the precise API calls and data formats for this interaction. Similar to RTP, this work is closely aligned with the EPC's VOP scheme, ensuring a consistent and interoperable approach for all market participants across Europe.