You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ThirdPartyAccess is a role specifically designed for open banking environments, where an account holder or another entity with operational access (but without access management rights) can delegate certain types of account permissions to a third party. This delegation allows authorized third-party providers (TPPs) to access the account or initiate transactions on behalf of the account holder. The scope of this access is strictly defined and limited to the specific consents granted by the account holder or operational entity.
Third-party access is integral to the open banking ecosystem, enabling various services like account aggregation, payment initiation, and balance confirmation, all while maintaining high levels of security and compliance with regulations such as PSD2 (Payment Services Directive 2) in Europe.
Key Characteristics:
Delegated, Limited Access:
ThirdPartyAccess allows a third-party service provider to access specific account functionalities, but the permissions granted are always limited to the scope defined by the account holder or operational entity.
This access can take several forms, such as:
Account Information Consent: Grants the third party read-only access to account details, transaction histories, and balance information.
Payment Initiation Consent: Allows the third party to initiate payments from the account on behalf of the account holder.
Confirmation of Funds Consent: Enables the third party to verify whether sufficient funds are available in the account for a transaction without revealing other account details.
These permissions are always time-bound and specific to the task or service requested.
Types of Consent and Permissions:
The permissions granted under ThirdPartyAccess typically fall into the following categories, commonly seen in open banking:
Account Information Consent (AISP - Account Information Service Provider):
Allows the third party to access the account holder’s financial data, such as balances, transaction histories, and account details.
The third party cannot make any changes to the account or initiate transactions but can use the data to provide services like financial management tools, budgeting apps, or account aggregation.
Payment Initiation Consent (PISP - Payment Initiation Service Provider):
Grants the third party the ability to initiate payments directly from the account, such as transferring funds or paying bills.
The third party acts on behalf of the account holder, executing payments that the account holder has authorized in advance.
Confirmation of Funds Consent:
Provides the third party with the ability to confirm whether the account has sufficient funds for a transaction, usually required during e-commerce purchases or other online payments.
The third party does not receive any additional account information besides the confirmation of available funds.
Other Open Banking Services:
As open banking evolves, other forms of ThirdPartyAccess may emerge, allowing for innovative financial services based on specific needs, such as recurring payment consents, automated investment services, or loan qualification checks.
No Access Management Rights:
A crucial aspect of ThirdPartyAccess is that the third party cannot manage or modify access for other users or roles within the account.
They are limited to performing the specific tasks for which they have been granted consent and cannot delegate their permissions to another party.
Granularity and Customization of Access:
The scope of ThirdPartyAccess can be highly granular, allowing the account holder to control the exact permissions and duration of access:
For example, an account holder might grant a payment initiation service permission to initiate payments up to a certain amount or within a specified period.
Similarly, they could allow an account aggregation service access to transaction history for the last six months, but no further.
These granular controls ensure that third-party providers can only access the data or perform the actions that are strictly necessary for the service they provide.
Time-Limited Access:
Access granted under ThirdPartyAccess is typically time-bound, meaning the third party has access for a predefined period or for a specific number of transactions.
For instance, account information consent might be valid for 90 days, after which the third party must request renewal from the account holder.
Weight:
The weight of ThirdPartyAccess typically depends on the level of control granted. For instance:
0.1 - 0.3: For read-only access (e.g., Account Information Consent) where the third party has minimal influence on the account.
0.5: For permissions that allow more operational activities, such as initiating payments.
The weight reflects the potential impact of the third party’s actions on the account but remains lower than direct account roles like HolderAccess or ManagerAccess.
Status:
The status of ThirdPartyAccess can change based on several factors:
Active: The third party has valid and ongoing access under the terms of the consent granted.
Expired: The consent has lapsed, and the third party no longer has access. Renewal is required for continued access.
Revoked: The account holder or operational entity has manually revoked the third party’s access, cutting off any permissions before the original consent period ends.
Status changes help maintain tight control over third-party access, ensuring that permissions are not misused or extended unintentionally.
Conditions and Restrictions:
The account holder or operational entity can impose specific conditions on ThirdPartyAccess to further restrict the scope and use of the permissions granted:
Monetary Limits: For payment initiation, the third party might only be allowed to initiate payments below a certain threshold.
Data Privacy Limits: In account information consent, certain sensitive data (e.g., specific transaction details) might be excluded from the third party’s view.
Geographical or Platform-Based Restrictions: Some consents may restrict access to specific platforms or geographic regions, ensuring that third-party providers can only operate within defined boundaries.
Example Workflow for ThirdPartyAccess:
Account Information Consent for a Budgeting App:
The account holder uses a third-party budgeting app that aggregates account data from various financial institutions.
They grant the app provider Account Information Consent, allowing the app to pull transaction data and balances from their bank account for a period of 90 days.
The app provides budgeting and financial analysis based on this data but cannot initiate transactions or access other areas of the account.
After 90 days, the consent expires, and the app can no longer access the account unless the holder renews the consent.
Payment Initiation for Bill Pay:
The account holder uses a third-party payment initiation service to automate bill payments.
They grant Payment Initiation Consent, allowing the service to initiate payments from their bank account to various billers.
The service can execute the payments but cannot view the account’s transaction history or balance unless explicitly allowed under separate consents.
The payment initiation consent is valid for six months, after which it must be renewed.
Confirmation of Funds for Online Shopping:
During an online purchase, the account holder gives a third-party payment processor Confirmation of Funds Consent.
The processor checks if the account has sufficient funds to cover the transaction without accessing the account balance or any transaction history.
Once the confirmation is completed, the processor moves forward with the transaction, but no further access is allowed beyond that specific operation.
Key Considerations for ThirdPartyAccess:
Security and Privacy: Open banking regulations, such as PSD2, ensure that third-party access is governed by strict security protocols and that consent must be clear, informed, and limited in scope. This protects the account holder’s data from being misused or accessed unnecessarily.
Revocability: The account holder or operational entity must have the ability to revoke ThirdPartyAccess at any time. This ensures that if a third party is no longer needed or trusted, their access can be quickly and easily removed.
Granularity of Permissions: The ability to define granular permissions is essential for managing risk. The account holder must be able to control exactly what data or operations the third party can perform, and these permissions should be adjustable over time.
Scenarios for Revocation or Expiry:
Completion of Service: Once a third-party service has completed its task (e.g., a payment or data aggregation), the consent can expire or be revoked, ensuring no further access is granted.
Security Breach or Misuse: If there is any suspicion that a third-party provider has misused the granted permissions, the account holder can revoke access immediately.
Changes in Service Terms: If the third party changes its terms of service or introduces new features that the account holder is uncomfortable with, they can choose to revoke or not renew the access.
Example Use Cases:
Personal Finance Management: Many consumers use third-party apps to manage their personal finances, such as budgeting tools or investment trackers. These apps rely on Account Information Consent to pull in data from various accounts without compromising security or giving full account access.
Automated Payment Services: Businesses and individuals often use third-party services to automate recurring payments, such as rent or utility bills. Payment Initiation Consent allows these services to initiate payments without revealing the full account details to the service provider.
E-commerce and Payments: Online retailers and payment processors frequently use Confirmation of Funds Consent to ensure that a buyer has sufficient funds for a transaction without requiring full access to the account’s financial data.
The text was updated successfully, but these errors were encountered:
Entity: ThirdPartyAccess
Overview:
ThirdPartyAccess
is a role specifically designed for open banking environments, where an account holder or another entity with operational access (but without access management rights) can delegate certain types of account permissions to a third party. This delegation allows authorized third-party providers (TPPs) to access the account or initiate transactions on behalf of the account holder. The scope of this access is strictly defined and limited to the specific consents granted by the account holder or operational entity.Third-party access is integral to the open banking ecosystem, enabling various services like account aggregation, payment initiation, and balance confirmation, all while maintaining high levels of security and compliance with regulations such as PSD2 (Payment Services Directive 2) in Europe.
Key Characteristics:
Delegated, Limited Access:
ThirdPartyAccess
allows a third-party service provider to access specific account functionalities, but the permissions granted are always limited to the scope defined by the account holder or operational entity.Types of Consent and Permissions:
The permissions granted under
ThirdPartyAccess
typically fall into the following categories, commonly seen in open banking:Account Information Consent (AISP - Account Information Service Provider):
Payment Initiation Consent (PISP - Payment Initiation Service Provider):
Confirmation of Funds Consent:
Other Open Banking Services:
ThirdPartyAccess
may emerge, allowing for innovative financial services based on specific needs, such as recurring payment consents, automated investment services, or loan qualification checks.No Access Management Rights:
ThirdPartyAccess
is that the third party cannot manage or modify access for other users or roles within the account.Granularity and Customization of Access:
ThirdPartyAccess
can be highly granular, allowing the account holder to control the exact permissions and duration of access:Time-Limited Access:
ThirdPartyAccess
is typically time-bound, meaning the third party has access for a predefined period or for a specific number of transactions.Weight:
weight
ofThirdPartyAccess
typically depends on the level of control granted. For instance:weight
reflects the potential impact of the third party’s actions on the account but remains lower than direct account roles likeHolderAccess
orManagerAccess
.Status:
ThirdPartyAccess
can change based on several factors:Conditions and Restrictions:
ThirdPartyAccess
to further restrict the scope and use of the permissions granted:Example Workflow for ThirdPartyAccess:
Account Information Consent for a Budgeting App:
Account Information Consent
, allowing the app to pull transaction data and balances from their bank account for a period of 90 days.Payment Initiation for Bill Pay:
Payment Initiation Consent
, allowing the service to initiate payments from their bank account to various billers.Confirmation of Funds for Online Shopping:
Confirmation of Funds Consent
.Key Considerations for ThirdPartyAccess:
ThirdPartyAccess
at any time. This ensures that if a third party is no longer needed or trusted, their access can be quickly and easily removed.Scenarios for Revocation or Expiry:
Example Use Cases:
Account Information Consent
to pull in data from various accounts without compromising security or giving full account access.Payment Initiation Consent
allows these services to initiate payments without revealing the full account details to the service provider.Confirmation of Funds Consent
to ensure that a buyer has sufficient funds for a transaction without requiring full access to the account’s financial data.The text was updated successfully, but these errors were encountered: