Consent Scope & Attributes
Version | Changes | Date Updated |
|---|---|---|
v1.2 |
| Jan 26, 2026 |
v1.1 | First publication |
|
What does the consent scope cover?
Consent Info Page | Consent Scope |
|---|---|
 | What data is the user sharing? As defined in Data Structure workstream |
How long back in history is the user sharing data? | |
For what purpose is the user sharing data?
| |
How long is the user providing access to their data for? |
Consent Record
Each consent is stored as a structured record that defines what data can be accessed, by whom, for what purpose, and for how long.
Below are the fields captured in every consent object:
Attribute | Field | Example |
|---|---|---|
1 | abc123 | |
2 | <unique identifier for the end user> | |
3 | Paybank | |
4 | RinggitSen | |
5 | <list of Accounts that will be shared> | |
6 | credit_underwriting, personal_finance_management | |
7 | ReadAccounts, ReadTransactions, ReadBalances | |
8 | 180 days | |
9 | 12 months | |
10 | Authorized |
Consent Attributes
(1) ConsentID
How ConsentIDs are generated and managed to ensure proper data access control.
Each consent issued within the Open Finance ecosystem is uniquely identified per authentication & authorisation, and managed through a ConsentID, with one ConsentID assigned for each specific consent purpose.
ConsentID ensures each user’s data-sharing agreement is uniquely tracked and managed, providing clear audit trails, preventing unauthorised scope changes, and maintaining data integrity across all ecosystem transactions.
Rule | Explanation | How It Works |
ConsentID Issuance & Uniqueness | A ConsentID is created for every unique DP–DC–User-Purpose combination. |
|
Multiple Active ConsentIDs | Multiple active ConsentIDs simultaneously per DP–DC–User, each representing a single-purpose consent |
|
Consent Is Non-Editable | Existing consents cannot be modified. | A new consent journey must be initiated each time any parameter needs to be changed. |
What happens if a user already has an active consent with the DP-DC combination for a specific use case, and additional consent is being triggered for a 2nd use case:
(2) Unique User ID
How a unique user ID acts as the anchor for identity.
A Unique User ID (UUID) is an identifier that securely links a user’s identity and consent across multiple data providers and consumers without exposing personal information.
Why is this needed?
🔐 Protects customer privacy – Enables consent tracking without exposing personal data
🔗 Ensures interoperability – Links the same user across multiple data providers and consumer
📍 Tracks consent lifecycle – Supports creation, update, and revocation of consents accuratel
🧾 Enables auditability – Provides a consistent reference for compliance and dispute resolution
🛡️ Reduces fraud risk – Prevents unauthorized access by ensuring requests are tied to valid, issued consents
⚙️ Supports scalability – Allows centralized platforms to manage millions of users without storing PII
(3 & 4) Data Provider and Data Consumer
Ecosystem participant transparency for both Data Providers and Data Consumers.
(5) AccountID
Accounts that a user authorizes a Data Provider to share to a Data Consumer.
The Account ID is a unique identifier for a specific financial account held by the user, such as a bank account or EPF account.
Why is it important?
Allows the user to share only specific accounts they consent to.
Enables the Data Provider to locate and share only the account data that the user has explicitly consented to.
Aligns with data protection principles like purpose limitation and informed granular consent which fits within BNMs MCIPD compliance framework.
Account Types DPs must support
as defined in the Data Structure workstream
Savings & Current accounts (CASA) → Full account number
Credit Card → Masked number
Return first six and last four digits, with the middle digits replaced by * (e.g. 123456******7890. )
Loans: Hire Purchase & Mortgage → Full account number
For the Account Types stated above, DPs are to provide
Active accounts only → accounts where customers are able to view and transact
Other account status (eg. dormant, inactive, mule etc.) should be not listed as an option for users to select, and data sharing for these accounts should not be allowed.
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.
(6) Purpose
What is the purpose of sharing the data.
Only data related to the Consent Purpose can be requested.
This framework defines a list of standard consent purposes, each mapped to a specific set of data permissions.
Each purpose must be declared by the DC when initiating a consent request.
All purposes are whitelisted and approved by PayNet via the PayNet Open Finance Platform.
DCs can only select from this approved list when requesting consent.
Consent is always tied to one specific, declared purposes.
A single consent object can include one (1) declared purposes, depending on the use case.
Table below shows examples of supported use cases, their mapped purposes and the data permissions enabled for each:
Use Case | Consent Purpose | Data Permissions |
Personal Finance Management (PFM) | personal_finance_management | ReadAccounts, ReadBalances, ReadTransactions |
Credit Underwriting | credit_underwriting | ReadAccounts, ReadBalances, ReadTransactions |
(future) Account Verification | account_verification | ReadAccounts |
(future) Payments | payments | ReadBalances |
(7) Data Types
This section covers the 3 data types & the data recency details:
(8) Consent Validity Period
How long can data be shared for?
Consent validity period defines how long a consent remains active and usable. It determines the period during which a Data Consumer (DC) can access a user’s financial data from the Data Provider (DP).
Why is this needed?
This mechanism ensures time-bound user control and prevents stale or dormant data access
Starts: From the moment the user authorizes the consent after authentication
Ends: After a fixed duration (e.g. 180 days) or earlier if revoked
All accounts under a single consent share the same data permissions and consent validity period.
What Happens At The End Of The Consent Validity?
Consent status transitions automatically to “Expired”
All linked consents are invalidated immediately.
Any attempt to access user data using expired consent will be rejected.
DCs must initiate a new consent journey if access is still required.
Proposed Validity Period
PayNet Open Finance Platform centrally sets and enforces the consent validity duration options.
It is standardized across the ecosystem.
Consent durations should be long enough to avoid user fatigue, but short enough to protect trust and control — always anchored on the purpose, risk, and user value.
How it works:
The PayNet Open Finance Platform will offer two fixed validity options
Duration of active consent | Relevance to Use Cases |
60 days | Credit Underwriting only |
180 days | Personal Finance Managemeny only |
DC sets the duration needed during the consent initiation stage.
Most global Open Finance platforms start with shorter validity periods (typically 3 – 6 months)
As ecosystems mature and trust strengthened,durations were extended — with platforms now supporting 6 - 36 months
(9) Transaction History Period
How far back should data be shared?
The transaction history period defines the range of past dates for which transaction data can be accessed. This range is recorded in the consent object and determines the earliest and latest transactions retrievable by the Data Consumer (DC).
How It Works:
PayNet Open Finance Platform defines the supported range (12 months)
The user cannot modify this data period
All accounts under the same consent will follow the same specified range
DP Category | Data availability | Data to be shared |
Banks & EPF (12 months) | If the account has >12 months of data | DP to provide full data from the 12 months |
If the account has <12 months of data | DP to provide the full data that is available |
Majority are min. 12 months:
Malaysian landscape and use cases:
Personal Finance Management (PFM)
Min. 12 months would be sufficient in providing
Meaningful financial insights to the user & DC — year-over-year spending, seasonality
Smarter recommendations from DCs — savings goals, subscription tracking
Stable behavioral analysis (vs. short-term anomalies)
Credit Underwriting
Between 12-24 months for a more accurate evaluation of income stability, spending behavior, and risk.
(10) Consent Status
The consent status determines whether the Data Consumer has access to request for data from the Data Provider.
Transitions:
Initial Status → | Transition To (Enhanced) | Scenario |
Awaiting Authorization | Authorized | If user approves in the DP app |
Failed | If no action in 5 mins (eg. user drops off or if there is network issue) | |
Rejected | If user declines / reject in the DP app, or DP reject the consent as part of its system-side validation, risk assessment, policy checks, or technical/business rules. | |
Authorised | Suspended | If flagged by DP/DC/platform (e.g. fraud) |
Expired | Automatically at the end of validity period | |
Revoked | If user, DC, or DP revokes manually or through account deletion | |
Suspended (Used for fraud investigation etc) | Authorized | Returns to Authorized if issue cleared |
Revoked | If after issue is confirmed and no intention to change status to Authorized 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 never approved. |
Failed | No transition. | Final state. Authorization for consent failed within 5 minutes. |
Additional Scenarios:
No | Scenarios | Actor Who Triggers | Status Changes |
1 | DC initiates consent request, and user yet to respond | User via DC | → Awaiting Authorization |
2 | User authenticates and approves consent | User via DP | Awaiting Authorization → Authorized |
3 | User declines / reject consent during initiation | User | Awaiting Authorization → Rejected |
4 | DP reject the consent as part of its system-side validation, risk assessment, policy checks, or technical/business rules. | DP | Awaiting Authorization → Rejected |
5 |