DP Universal Link
Version | Changes | Date Updated |
|---|---|---|
v1.0 | First publication | Apr 2, 2026 |
Overview
From the Data Consumer App, when a customer has selected a Data Provider and wants to proceed with the account linking, they will be redirected to the Data Provider’s platform to complete the authentication & authorization.
Universal Link will be the sole method for authentication and authorization redirection to the DP app, as this approach provides the best and most seamless user experience:
Prioritizes App-to-App flow;
While supporting a fallback to DP web login flow if the customer does not have the app installed in the DC Device.
Therefore, this specifications document details out the Universal Link structure and requirements that a Data Provider must implement for the Open Finance consent flow.
Note: As a best practice, the DP Universal Link should be designed to gracefully handle scenarios where the user’s OS or DP app version is unable to fully process the link (eg. outdated OS / DP app version). In such cases, the DP should implement appropriate fallbacks, such as redirecting them to update to latest app or fallback to DP’s secure web login page to continue the journey.
Additionally, the DP’s web login and consent flow should be built with responsive design principles, ensuring a consistent and seamless experience across both mobile and desktop browsers.
Universal Link Structure
https://domain.com/OFM/MY/Authorize/AIS?consent_id={consent_id}&signature={signature}&redirect_uri={redirect_uri}
: Domain
: Product
: consent_id
: signature
: redirect_uri
Component | Parameter | Description | Available Value |
|---|---|---|---|
Domain | - | This component includes the scheme and authority, which together define the redirection address and indicate the destination the customer will be directed to. Participants have the flexibility to determine this domain based on their internal policies and technical architecture.
| Example value:
|
Path Segment | - | This component comprises the system identifier (OFM), country code (MY), and action type (authorize). These elements will remain consistent across all products for app-based redirection. | /ofm/my/authorize |
Product | - | This component serves as an indicator of the specific product associated with the redirection process. |
|
consent_id | consent_id | This component represents the unique identifier for the transaction (consent) being redirected. | Example value: |
signature | signature | The | Example value: |
redirect_uri (PayNet) | redirect_uri | This component refers to PayNet’s redirect_uri. PayNet will then handle the redirection back to the DC App based on the redirect_uri that was sent by the DC through the | Example value: redirect_uri=https://api.as.openfinance.dev.inet.paynet.my/consent-authorize?consent_id=18ce19c8-85be-4049-899c-21cdc02cde79 |
Universal Link Redirect and Invocation Sequence
At Step 16, the DC redirects the End User’s browser to the OFP AS /authorize endpoint, including the client_id and request_uri.
At Step 17, the OFP AS retrieves and resolves the consent context associated with the request_uri.
At Step 18a, the OFP AS returns an HTTP 302 response, with the Location header set to the DP Universal Link, embedding the consent_id, redirect_uri, and signature.
At Step 18b, the End User’s browser automatically follows the redirect and performs an HTTP GET request to the DP /authorize endpoint.
At Step 19, the DP must validate the signature using the PayNet public key and reject the request if validation fails, before resolving the consent using the consent_id.
At Step 20, the DP authenticates the End User, presents the consent details and account selection, and captures the user’s authorization decision.