Yes, all Data Providers (DPs) and Data Consumers (DCs) must follow the same redirection, consent, and authorisation flows per the Open Finance Malaysia - UIUX Guidelines.

Yes, the UI/UX Guideline will include terminology to be used in dual language. This means standardised terminology across all screens, along with a consistent tone that’s simple and clear.

We’ll also support dual-language (BM & English at the minimum) to ensure the experience is inclusive and easy to understand for all users. (Note: The UIUX Guideline is published for the English language, BM language will be provided at a later date.)

All screens in the account linking and management of linked accounts journey must follow OFM’s Open Finance Malaysia - UIUX Guidelines to ensure consistent, trusted experience across participants.

OFM provides:

• Key UI designs for consent flows (detailed in guidelines)

Exceptions (DC-specific flows that may vary based on each DC’s product design):

• Product entry points

• DC's own product disclosure/flows

DP/DC responsibility: Build all remaining screens per guidelines.

Yes, participants need to follow the Link Element as per the UIUX Guideline, where the DC and DP logos are dynamic (based on the consent).

This Link Element Asset together with the Participant Logos are shared in the Design Assets Figma Link within the UIUX Guideline document.

Open

If the DC's refresh mechanism pulls the data for all account id-s, then yes you may display a "last updated" timestamp that covers all listed accounts.

The guiding principle here should be that the information of the "last updated" timestamp shown is accurately displayed to the customer.

Yes it is mandatory to use the term "Credit Underwriting" and “Personal Finance Management (PFM)” for the consent purposes. DCs should educate and inform users on what this term means before they invite users to start linking their account.

Open

Yes, participants must follow the exact text here with the Data Provider name as the dynamic content.

Yes. OFM will provide the standard Open Finance DP and DC T&Cs for the participants to incorporate into the consent journey.

Yes. OFM will share the standard FAQs related to the consent. However, DC & DP should prepare their own FAQs for their respective product & use cases.

Yes, users can link multiple banks. After completing the first link, they return to the dashboard and restart the process to add another Data Provider (DP).

Yes — this version of the user journey is specific to retail customers and applies only to individual accounts, not joint or business accounts. Our current focus is on the Initial Launch. As we expand to cover SME use cases, we’ll share updated user journey guidance if needed.

Open

Yes, DCs may add an entry point to link their accounts here. However, please note that the entrypoint to the account linking flow should be use-case specific. Therefore even if you add an entry point in this Manage OFM Link(s) screen, the use case should be upfront and made clear to the customers so that they know what they are consenting to.

If it is for the same use case, then yes, DCs must first notify users that there is already an existing consent and whether they want to proceed to re-link. If a new consent is initiated, DPs are then expected to revoke the previous active consent before authorizing the new one.

Yes, there is a provider_type in the Providers API, and this list of types will continue to expand as our participant base grows.

Yes, both the Data Consumers (DCs) and Data Providers (DPs) have to host the dashboard. This is so that end-users are able to manage their linked accounts from either apps.

This has been amended to “Management OFM Link(s)” in the latest UIUX Guideline.

No. This focuses only on the User Journey UI/UX for consent flows. Consent management lifecycle and consent key principle are addressed separately under the Consent Framework Workstream.

No, participants should use the same terms for the consent status as per the UIUX Guideline to ensure that it is consistent and recognizable by customers throughout the ecosystem.

Participants may follow their colour system, as long as it matches the similar colour tone as per the guideline. PayNet will review the Banks colour code application during the UX certification process

Yes, as mentioned in the guideline - the DCs should prompt users to renew their consent before it expires. It is up to the DC on when they want to prompt this renewal. However, please note that this renewal is actually a revocation and re-initiation of a new consent as per the consent ID rule.

Consent Validity Period is fixed based on the 2 use cases:

• PFM: 180 days

• CU: 60 days

Similar to payment flows, and in line with RMiT’s requirements for secure device-bound authentication, authorisation must be completed in a secure, authenticated environment — within the DP’s app. Therefore, if a user begins the journey on the DC’s website, the DP app will still be needed to complete the authorisation.

If the DP’s app is unavailable, the user will not be able to complete the authorisation flow, as these steps are required to be performed in the DP app — similar to payment flows.

This is an edge case. However, if both apps are supported for Open Finance use cases, users may be prompted to choose through a DP hosted landing page during the redirection journey. If there are many such cases, PayNet may consider supporting more than 1 app per institution.

Similar to payment flows, and in line with RMiT’s requirements for secure device-bound authentication, authorisation must be completed in a secure, authenticated environment — within the DP’s app.

When the DC and DP apps are installed on different devices, the DP Universal Link ensures a seamless and secure continuation of the account linking journey across devices.

The user begins the journey in the DC App (Device 1), they are redirected to the
DP’s web login page in a browser to login and select their accounts. During the authorisation step, the DP App (in Device 2) will receive a push notification prompting the user to complete the authorisation in that device. Please refer to the Open Finance Malaysia - UIUX Guidelines for the user journey flow.

For the pilot phase, we are focusing on app-to-app and web-to-app redirection to streamline development and leverage familiar authentication & authorization flows for payments.

As a best practice, the Data Provider (DP) Universal Link should be designed to gracefully handle scenarios where the user's operating system or application is unable to fully process the link (e.g. application not installed, unsupported or outdated application version, or OS limitations). Appropriate fallback mechanisms should be implemented, such as prompting the user to install or update the application, or redirecting the user to the DP's secure web login page to continue the authorisation journey.

The specific implementation of these exception scenarios is left to each participant, and PayNet does not prescribe a single implementation approach.

An illustrative example of one possible implementation is provided for reference. Participants may adopt an alternative approach based on their own application design.

Open

It is currently only prescribed for consent initiation (DP) in the Open Finance UI/UX Guideline.

It is not prescribed at OFM scheme level. DC is required to make assessment based on specific use case.

• Individual Retail Customer Accounts only

  • Joint accounts, SME accounts etc. are not part of the scope currently.

• MYR Accounts only, foreign accounts are not part of the scope currently.

Note: Data Providers must only allow for Active accounts to be linked for data sharing. Dormant, Inactive, Mule Accounts etc. should not be shared in the Open Finance Malaysia ecosystem.

Account Types for Banks:

• Savings & Current Account (CASA)

• Credit Card

• Hire Purchase

• Mortgage

Account Types for EPF:

• Pension

Only active accounts can be linked for data exchange. If a linked account becomes inactive at any point during the consent validity period, the consent remains active until the expiry date, however data exchange for that account will cease and no further data will be shared.

For scenarios involving dynamic or dummy card numbers, the platform will pass through whatever information the DP provides to the DC.

If the bank manages dynamic numbers internally, the DC will still receive the transaction under the same credit card account, ensuring continuity and traceability.

Yes – credit limit data is essential for the following two use cases:​

1. Personal Financial Management (PFM):
   Enables users to calculate credit utilisation ratios, offering better insights into their financial health and credit usage.​

2. Credit Underwriting:
   Helps lenders assess a borrower’s creditworthiness by evaluating credit limits in relation to outstanding balances—supporting more informed lending decisions.

Institution names will be standardised by OFM during the Open Finance onboarding process. A standardised list will be published to ensure consistency across the ecosystem.​

Yes, personal loan data from Data Providers are not part of scope currently. However, DCs can still obtain a full view of the user’s financing exposure through the normal CCRIS process.

This will follow each bank’s existing card architecture.

Each card (primary and supplementary) is typically represented as its own account because it belongs to a specific individual.

If the bank structures the credit balance as shared across the cards, this will be reflected accordingly in the balance data structure.

The primary cardholder must provide consent if data related to supplementary card usage is to be shared.

Joint account is not part of the scope. As for loan, the current scope is only for Hire Purchase and Mortgage. Joint account for loan product also not part of the scope.

No, DP is required to only show the Active accounts. Inactive, mule, dormant etc. accounts should not be included.

The 'Balance' and 'Transaction' data are separate APIs, so there is no partial success response as this is not possible.

For depository accounts (CASA), if the overdraft facility is utilised, the current balance will appear as a negative value to reflect the amount drawn against the OD limit. The OD limit itself is not included in the Account or Balance reporting.

Yes we need a balance endpoint –​

• Including it in the account endpoint isn’t appropriate as account data is mostly static, while balance is dynamic.​

• Including it in the transaction endpoint is inefficient, as some use cases only require balance data. Forcing a call to transactions just to retrieve balance would increase unnecessary load and complexity.

Data Providers are required to provide current and available balance data in real time. ​

For non real time statement, there will be statement balance date.

Only accounts with Statement Balance are required to pass the data for these 2 fields.

• statement_balance refers to the latest available monthly Statement balance or Ending Balance for the account.

• statement_date refers to the date of said statement_balance.

This will be as per system generated, meaning the same Description shown in the bank app should be shown for this field.

The associated account_id is included in the transaction endpoint to facilitate cross-referencing between transactions and their associated accounts number.

Beneficiary name, payment or transfer details can be added in the description / recipient_reference / other_payment_description.

There will not be an indicator specifically for Salary related transactions, however DCs can match it against the transaction description coming from the DP.

Yes, EPF will provide this in the Transaction API, and the 'Description' will indicate whether it's Caruman Majikan or Caruman Ahli. Please refer to Data Structure - Transaction for more details on EPF transaction data.

No, ‘Employer Name’ will not be provided by EPF as this field currently is not present in EPF statement as well.

As a DP:

1. For the initial Pilot Launch: As per the OP, it defines the DP’s obligation of providing data that is complete, accurate, and consistent with their internal system-of-record values.​

2. During the stabilisation phase: DPs should work towards providing data freshness as below:

• CASA: For Current and Available Balance, must be real-time.

• Other fields, data types and account types can be batch update with maximum 1-day latency.

As a DC:
This is up to the DC on how often they want to refresh the data. This depends on how you build your use cases & features, but do note that data recency and relevancy are important to users to make informed decisions.

Yes, you may. The OP defines that DPs must delete the data without undue delay, this daily batch deletion is considered reasonable.

The following Resource APIs will incur cost:

• Account API

• Balance API

• Transaction API

 Yes, in the Provider object there is provider_type which indicates whether the DP is a bank or pension_fund. In the future as more DPs are added in, this list of provider_type may expand.

We do not limit the data field lengths as this depends on the DP’s data. However, DCs may handle the UI design according to what works best for your feature.

Yes, that’s right. The Consent Purpose is determined by the entry point based on the DC’s product flow for the use case.

No, they cannot. Each consent_id is tied to a specific consent purpose, either PFM or Credit Underwriting.

For now, linking to each DP requires it’s own consent initiation because the end user is required to authenticate & authorize the consent on the specific DP app. Therefore, it is not possible to get bulk authorisation from multiple DPs at one-go. However, we are aware of this and will explore it as an optimization to the user journey in the future.

Any consent obtained under Open Finance Malaysia (OFM) must comply to prescribed Consent Framework.

Open

Yes, customer is allowed to select a range of accounts to be linked to a consent. However as per the UIUX Guidelines, if no accounts are selected in the "Account Selection Page" in the DP app, the DP should grey out & disable the Link Account(s). Customers must select at least one account for them to be able to proceed to the next step in the consent flow.

Based on the ED and OP, yes. The data consumer shall, without undue delay, securely delete all customer information that was obtained under the withdrawn consent, unless retention is required under applicable laws or regulatory requirements.

Open

Is this referring to the hashed_id_number in the consent object? If so, yes this hased_id_number should be the customer’s NRIC (for Malaysian) or passport number (for foreigners). There is an id_type indication to distinguish between the two. Please refer to the API specs for the guidance on hashed_id_number.

• From the customer’s POV, DCs may prompt their customers to renew a consent that is expiring. However in the backend, it is actually an initiation of a new consent and the old consent must be revoked. This is because there can only be 1 active consent_id for a DP-DC-User-Purpose combination.

• It is up to the DC on when they want to prompt users to renew their consent.

If it’s the same DP-DC-User-Purpose condition, then yes that’s right. This is because there can only be 1 active consent_id for a DP-DC-User-Purpose combination.

The validity period starts from the new consent initiation date.

Yes, customers are allowed to select different accounts.

For consent “renewal”, customers do not need to be explicitly informed that the old consent has been revoked. But DC’s should inform them that the new consent has been granted.

If it’s the same DP-DC-User-Purpose combination, then yes that’s right. This is because there can only be 1 active consent_id for a DP-DC-User-Purpose combination.

• Yes, only participants (DP/DC) can suspend a consent. A user cannot suspend the consent from the app.

• Yes, a webhook notification will be sent to the other party if there is any update in the consent status.

When a consent is suspended, there are a few possible transition scenarios:

1. If suspended consent has not reached the expiry date, customer can choose to revoke the consent from the app.

2. If suspended consent has not reached the expiry date, DC/DP decides to reactivate/revoke the consent based on the investigation outcome.

3. If suspended consent reaches the expiry date, the consent status will automatically be updated to expired.

This depends on the participants SOP for suspicious activity or fraud.

Yes, either DP or DC may suspend a consent where fraud, unauthorized activity, or compromise of customer credentials is reasonably suspected.

The suspending Participant shall notify of the suspension and subsequently outcome. Disclosure of reason is not mandated.

After the end user provides consent, the Data Consumer (DC) retrieves data via a server-to-server API call to the Open Finance Platform, in accordance with the published API Specifications.

The central platform facilitates secure data exchange between the Data Consumer (DC) and Data Provider (DP) servers.

Yes. PayNet adopts an API Hub model where the platform facilitates data exchange between Data Providers (DPs) and Data Consumers (DCs).

Participants joining the platform can connect with other enabled participants without building point-to-point integrations.

All data exchanged is end-to-end encrypted, and PayNet does not have visibility into the data payload.

Yes. PayNet provides a sandbox environment for development and pre-production testing. Details will be shared in the Participant Onboarding Guide.

Yes. Any proposal for new endpoints or data models must be reviewed and approved by the PayNet Open Finance team. Standard endpoints and data models have been finalised for the initial release.

Participants must register their universal links through the PayNet Developer Portal during onboarding.

If there is sufficient demand from participants, PayNet will consider providing SDKs. Participants are encouraged to provide feedback during the participant enablement phase.

Data Consumers must manage data retention and deletion in accordance with the Bank Negara Malaysia (BNM) Exposure Draft on Open Finance and the OFM Operational Procedure.

If a timeout or error occurs, clients should retry the request using the same idempotency key to ensure only a single operation is processed and to prevent duplicate data retrieval. Further details are available in the API Specifications.

The API Specifications provide guidance on how custom fields may be used by Data Providers and Data Consumers while maintaining compliance with standard data structures.

No. Data Providers must provide a minimum of 12 months of data. Partial or range-based access based on internal system availability is not supported, as it limits ecosystem value and use case consistency.

Participants must engage their own Certificate Authority and submit certificates to PayNet. TLS version 1.2 and above is supported.

Our key management and rotation policy ensures security and integrity of cryptographic keys used in our system:

• Key Rotation: Keys are rotated manually every 12 months.

• JWKS Overlap: A new key is introduced 30–60 days before the old key expires to ensure smooth transition.

• Key Lifetime: Each key has a maximum lifetime of 12 months.

• Compromised Keys: If a key is compromised, it is immediately removed from the JWKS and affected parties are notified via email.

• Private Keys: Private keys are never shared externally; HSM (Hardware Security Module) usage is not applicable in this setup.

This policy ensures secure key handling, smooth rotations, and timely notifications in the event of security incidents.

Answer is B

B. Centrally registered and hosted under PayNet's governance. But certs are provided by the participants.

Pagination improves performance by returning data in small, controlled chunks instead of loading everything at once, which reduces database load, lowers memory and bandwidth usage, and keeps the system fast and stable even with large volumes.

We don’t force upgrades directly, we set minimum technical and SLA requirements, and systems that can’t meet them simply won’t pass onboarding.