Integration Flow
- 1 Overview
- 2 1. High-Level System Architecture
- 2.1 Key Actors
- 2.2 How It Works
- 3 2. End-to-End Flow: Authorisation Endpoint
- 4 3. End-to-End Flow: Resource Endpoint
- 5 4. End-to-End Flow: Data Refresh
- 6 Token Types & Response Signature
- 7 Async vs. Sync Data Retrieval Approach
- 8 Proposed Timeouts and Handling
- 9 Consent Lifestyle Management
- 10 Not finding the help you need?
Overview
The integration flow describes how the different systems (Data Consumers and Data Providers) securely exchange financial data through the PayNet Open Finance Platform.
These flows cover the journey from when a user wants to grant permission for data sharing and ends with being able to see their data in the app.
1. High-Level System Architecture
This diagram illustrates how the PayNet Open Finance Platform enables secure and standardized data sharing between Data Consumers (DC) and Data Providers (DP).
Key Actors
| Entities that request access to financial data, such as:
|
| Entities that own and supply the data, such as:
|
| Acts as a secure bridge between Data Consumers and Data Providers. It includes:
|
Security Highlights
FAPI (Financial-grade API) - Ensures APIs meet strict security and privacy standard.
mTLS(Mutual TLS) - Both parties verify each other’s identity before exchanging data.
End-to-End Encryption - Protects the data during transfer.
How It Works
A Data Consumer (e.g., a budgeting app) requests access to a user’s financial data. The request goes through PayNet platform, which:
Validates the Data Consumer’s identity.
Confirms user consent.
If approved, the platform securely retrieves data from the Data Provider (DP) and delivers it to the consumer.
This architecture ensures secure, consent-driven and standardized data sharing across multiple financial institutions, giving users control and protecting their privacy.
2. End-to-End Flow: Authorisation Endpoint
This flow explains how a user grants consent and authenticates their identity to enable secure data sharing between a Data Consumer (DC) and a Data Provider (DP) through the PayNet Open Finance Platform.
Step-by-Step Process
Step 1: User selects a Data Provider and consents to share data via their device.
Step 2: The Data Consumer sends a user authentication request to PayNet.
Step 3: PayNet verifies the identity and legitimacy of the Data Consumer.
Step 4: User is securely redirected to the Data Provider to log in.
Step 5: User chooses which accounts data to share with the Data Consumer.
Step 6: Data Provider confirms authentication and sends ID tokens to PayNet.
Step 7: PayNet generates secure tokens for the Data Consumer to access the authorized data.
Security Highlights
FAPI (Financial-grade API) ensures strong security and privacy.
Tokens (Access & Refresh) are used instead of passwords for secure, time-limited access.
User consent is central to the process.
This flow ensures that only authorized apps can access user data, and users remain in full control of what is shared and for how long.
3. End-to-End Flow: Resource Endpoint
This flow explains what happens after the user has authorised data sharing and PayNet has issued access and refresh token to the Data Consumer (DC). At this stage, the DC can securely retrieve user data from the Data Provider (DP) using those tokens.
Step-by-Step Process
Step 1: On their device, the user selects the Data Provider (e.g., a bank) and gives consent to share data.
Step 2: The Data Consumer sends an authentication request to PayNet.
Step 3: PayNet verifies the Data Consumer’s identity.
Step 4: The user is redirected to the Data Provider and logs in securely (App-to-App or Web-to-App)
Step 5: The user chooses which data (e.g., account details, transactions) to share.
Step 6: The Data Provider confirms authentication and sends ID tokens to PayNet.
Step 7: PayNet provides secure tokens to the Data Consumer for accessing data.
Step 8: The Data Consumer uses the access token to reuest data from PayNet’s Resource Endpoint.
Step 9: PayNet checks that the token is valid and the user consent matches the request.
Step 10: PayNet securely requests the authorised data from the Data Provider.
Step 11: The Data Provider sends the data back, signed and encrypted for security.
Step 12: PayNet ensures the data is authentic and untampered.
Step 13: The verifies data is encrypted and sent to the Data Consumer.
Step 14: The Data Consumer checks the data integrity and decrypts it.
Step 15: The user can now see the requested data in the app.
Security Highlights
FAPI (Financial-grade API) for strong security.
Open Finance API for standardised data exchange.
Digital Signatures & Encryption at every step to ensure data integrity and confidentiality.
This process ensures secure, consent-driven, and tamper-proof data sharing, giving users confidence that their financial data is protected end-to-end.
4. End-to-End Flow: Data Refresh
This flow explains how the refresh token is used to get a new access token, allowing the Data Consumer (DC) to continue retrieving updated data without requiring the user to log in again during the consent period.
Step-by-Step Process
Step 1: The user opens the app to view updated financial data.
Step 2: The Data Consumer uses the refresh token (previously issued) to request a new access token from PayNet.
Step 3: PayNet validates the refresh toke and issues a new access token to the DC.
Step 4: The DC uses the news access token to request updated data from PayNet’s Resource Endpoint.
Step 5: PayNet checks that the token is valid and the user’s consent is still active.
Step 6: PayNet securely requests the latest data from the Data Provider (e.g., bank).
Step 7: The Data Provider sends the updated data, signed and encrypted.
Step 8: PayNet ensures the data is authentic and untampered.
Step 9: The verified data is encrypted and sent to the Data Consumer.
Step 10: The Data Consumer checks the integrity and decrypts the data.
Step 11: The user sees the latest financial information on their device.
Security Highlights
Refresh Tokens allow secure, time-limited access without repeated logins.
Digital Signatures & Encryption ensure data integrity and confidentiality.
FAPI & Open Finance API standards maintain strong security and interoperability.
This offers a seamless user experience while maintaining high security and compliance.
Users do not need to re-authenticate every time the app needs updated data.
The process remains secure and consent-driven.
Token Types & Response Signature
Items | Usage | Description | Validity | Issued By |
|---|---|---|---|---|
JWT-Push Authorization Request (PAR) | Request for User Consent | Request message from DC to obtain user consent from DP | In-flight | DC |
Authorization Code (OAuth 2.0) | Return after consent authorized by user | Short-lived code (~ 1mins) used to exchange for tokens (ID, Access, Refresh) | ~ 1mins | PayNet OFP |
JWT Secured Authorization Response Mode (JARM) | Signed Authorization Code to protect integrity | RSA-signed authorization response by Data | In-flight | PayNet OFP |
Identity Tokens (ID tokens) | Proof of User Authorization by DP | OAuth token assigned by DP; to identify users and its related consent | One-time | DP |
Refresh Tokens | To exchange for new Access Tokens when expired |
| Follow consent validity | PayNet OFP |
Access Tokens | To retrieve Resource from DP |
| ~10 mins | PayNet OFP |
Async vs. Sync Data Retrieval Approach
PayNet’s Open Finance Platform uses a hybrid data retrieval model - combining Async for large data and Sync for real-time data.
This is aligned with global Open Finance standards and designed for efficiency and scalability.
Understanding Async vs. Sync Data Retrieval
When financial data is shared between banks and third-party platforms, it can be retrieved in two main ways.
Sync: The system waits for the data to be returned immediately. It is best for small or real-time data (e.g., checking account balance).
Async: The system processes large or complex data in the background and sends results later. It is best for batch or historical data (e.g, transaction lists).
Proposed Timeouts and Handling
Call Type | Proposed Data Delivery Period (For DP) | Handling if Timeout Occurs Beyond Data Delivery Period | Callback Expectations |
|---|---|---|---|
Synchronous /balances, /oauth, | Max 5 seconds for data delivery | Returns timeout error code. | N/A |
Asynchronous /accounts, /transactions |
|
|
|
Consent Lifestyle Management
The diagram below shows the different stages a consent request goes through from start to finish.
List of Consent Status
Initial Status → | Transition To (Enhanced) | Scenario |
|---|---|---|
Awaiting Authorisation | Authorised | If user approves in the DP app. |
Failed | If no action in x mins – i.e user drops off or if there is network issue. | |
Rejected | If user declines in the DP app. | |
Authorised | Suspended | If flagged by DP/DC/platform (e.g., fraud). |
Expired | Automatically at end of validity period. | |
Revoked | If user, DC, or DP revokes manually or through account deletion. | |
Suspended (Used for fraud investigation etc) | Authorised | Returns to Authorised if issue cleared. |
Revoked | If after issue is confirmed and no intention to change status to Authorised. User revoke while suspended. | |
Expired | If validity period ends during suspension. | |
Expired | No transition. | Final state. User must reinitiate a new consent from scratch. |
Revoked | No transition. | Final state. Consent terminated and access blocked. |
Rejected | No transition. | Final state. Consent was rejected by user. |
Failed | No transition. | Final state. Authorisation for consent failed within x minutes. |
Not finding the help you need?