Module 4: Advanced Framework Capabilities
Beyond the core and premium services, the openFinance framework includes several advanced capabilities designed to improve the efficiency, performance, and usability of the entire ecosystem. These services reflect the maturity of the standard and address practical challenges encountered in large-scale API deployments.
Push Notification Services
The original AIS model specified in NextGenPSD2 was based on a "pull" philosophy: the TPP periodically polls the ASPSP's API to request, or "pull," updated account information. While functional, this approach can be inefficient, generating significant network traffic and processing load, especially if data changes infrequently.
The Push Notification Service introduces an event-driven "push" model. Instead of the TPP constantly asking "Is there anything new?", the ASPSP can proactively "push" a notification to the TPP when a specific event occurs. This could be, for example, a new transaction being posted to a monitored account or a balance falling below a certain threshold.
The "Push Account Information Implementation Guidelines" specify how a TPP can subscribe to these notifications for a given account and defines the structure of the push messages that the ASPSP will send to a pre-registered TPP endpoint (a webhook). This shift from polling to webhooks makes applications more responsive and dramatically improves the efficiency of the system.
Resource Status Notification
Resource Status Notification is a specific and powerful application of the push model. It uses webhooks to asynchronously inform an API Client about a change in the status of a resource it has created, such as a payment or a consent.
Consider a payment initiation. After the TPP sends the POST request, the payment goes through several states at the ASPSP (e.g., Received, Pending, Accepted, Executed). In a pull model, the TPP would have to repeatedly call GET /v1/payments/{paymentId}/status to track this progress. With Resource Status Notification, the TPP can simply provide a Client-Notification-URI in the initial request header. The ASPSP will then automatically send a notification to this URI each time the payment status changes.
The "Status Notification Implementation Guidelines" provide the full technical specification for this service, including how the TPP registers its webhook URI and the JSON payload of the notification message. This capability is fundamental for building efficient and real-time payment tracking and consent management workflows.
The inclusion of push-based services marks a significant architectural evolution of the framework. It is a direct response to the practical limitations of the polling-based systems that characterised early open banking implementations. Constant polling is inherently inefficient, as it consumes network bandwidth and processing cycles on both the TPP and ASPSP sides, and it introduces unavoidable latency between when an event occurs and when the TPP discovers it. An event-driven, push-based architecture is far more scalable and performant. The TPP makes a single subscription request and then simply listens. The ASPSP sends a notification only when a relevant event happens. This architectural maturity demonstrates that the Berlin Group has learned from the real-world challenges of deploying APIs at scale and has evolved the standard to be more robust, efficient, and suitable for high-volume, real-time use cases.
The Discovery API
In a diverse ecosystem with thousands of ASPSPs, a TPP faces the challenge of discovering the specific capabilities of each one. Different banks may support different payment products, optional features, or versions of the API. Manually checking the documentation for each bank is not a scalable solution.
The Discovery API solves this problem by providing a standardised, machine-readable endpoint where a TPP can programmatically query an ASPSP's capabilities. This allows a TPP to automate its onboarding and configuration processes. Using the Discovery API, a TPP can find out information such as:
- Which versions of the openFinance API are supported.
- Which core services (AIS, PIS, FCS) are available.
- Which specific payment products (e.g., sepa-credit-transfers, cross-border-credit-transfers) are implemented.
- Which SCA approaches (Redirect, Decoupled, etc.) are supported.
The "Discovery API Implementation Guidelines" define the endpoints and data structures for this service, providing a crucial tool for interoperability and automation in a fragmented market.
Module 4 Quiz
1. What is the primary advantage of the Push Notification Service over the traditional "pull" model for account information?
2. How does a TPP typically subscribe to the Resource Status Notification service for a specific payment?
3. What problem is the Discovery API designed to solve?