Regulated frameworks in a number of jurisdictions allow authorised third parties to access bank account data, or to initiate payments, with the account holder's permission.
This describes how such arrangements generally work. Specifics vary by jurisdiction and the authoritative source is the relevant regulator.
The two distinct permissions
Frequently conflated and materially different.
Account information access allows a provider to read transaction data. It is read-only and cannot move money.
Payment initiation allows a provider to instruct a payment from the account, with the holder's authorisation for each payment or under a defined mandate.
Which means the risk profile differs substantially, and granting one does not grant the other.
How the access actually works
The mechanism matters because it determines the security position.
Authorisation happens through the bank's own authentication rather than by giving credentials to the third party.
Which means a provider asking for your banking username and password is not operating within the regulated framework, and that is the clearest possible warning sign.
The bank issues a token to the provider, scoped to specific data and a defined period, which the bank can revoke.
What is time-limited
A protection built into the design.
Access permissions generally expire and require renewal, commonly after a defined number of months.
Which means an arrangement forgotten about eventually lapses rather than persisting indefinitely.
Renewal prompts arrive from the provider, and ignoring them is an effective way to end an arrangement you no longer want.
Revoking access
Available through two routes and worth knowing both.
Through the provider, which is the ordinary route.
And through the bank, which maintains a list of granted permissions and allows revocation directly, which is the reliable route if a provider is unresponsive or has ceased trading.
Checking that list periodically is a worthwhile exercise, since most people have granted more permissions than they remember.
What to check before granting
The practical diligence.
Whether the provider appears on the regulator's register of authorised firms, which is public and searchable.
What data is being requested, since a well-designed request is scoped to what the service needs rather than to everything.
How long the permission lasts.
What the provider does with the data, including whether it is shared or used for purposes beyond the service.
And how to revoke it, which should be stated.
The liability position
Worth understanding since it differs from unregulated arrangements.
Regulated frameworks generally place liability for unauthorised payments with the payment service provider, subject to conditions including the customer not acting fraudulently or with gross negligence.
Which is a meaningful protection and it depends on the arrangement being within the regulated framework.
Sharing credentials directly with an unauthorised service falls outside it, and the protections generally do not apply.
What it is genuinely useful for
Being fair, since the framework exists for reasons.
Aggregating accounts across providers into a single view, which makes the tracking exercise described elsewhere considerably easier.
Affordability assessment for lending, which can produce faster and more accurate decisions than manual document submission.
Accounting and bookkeeping, where automatic transaction import removes substantial manual work.
And payment initiation, which for some transactions is cheaper than card payment and settles differently.
The residual caution
Transaction data is detailed and revealing — where you shop, what you subscribe to, where you travel, who you pay.
Which means granting access is a meaningful disclosure, and the question of what a provider does with it beyond delivering the service is worth answering before rather than after.
Data protection rights generally include access and deletion, which are exercisable and are the backstop if an arrangement is later regretted.
Where it is heading
A development worth being aware of.
Several jurisdictions are extending similar frameworks beyond banking to other financial data — pensions, investments, insurance — under broader open finance initiatives.
Which would allow the same aggregation and permission model to cover a fuller financial picture.
Implementation is at different stages in different places and the direction is consistent.
The practical implication is that the diligence described above will apply to a wider range of services, and the habit of checking authorisation and scope before granting access is worth establishing now.
Screen scraping, and why it was replaced
Worth knowing because some services still use it.
Before regulated interfaces existed, aggregation services obtained data by logging into accounts using credentials supplied by the customer.
That approach gives a third party full access rather than scoped access, breaches most banking terms, and removes the liability protections that apply to authorised arrangements.
Regulated frameworks were introduced substantially to replace it with something safer.
Which means a service still asking for banking credentials is operating in the older model, and the practical response is to decline.
Business use
The same frameworks apply to business accounts and are widely used for accounting integration, which removes manual transaction entry.
The same diligence applies, with the addition that authority to grant access should sit with somebody who actually has it under the business's own arrangements.