Open Banking Foundations

Participants, consent, data access and payment initiation

A customer-directed connection

Open banking enables financial services to connect through controlled interfaces, often for customer-permitted account information or payment initiation. Some markets mandate defined access; others use commercial arrangements. It is not one global law, one API format or one payment rail.

In a typical budgeting journey, the customer chooses a provider, grants permission for an account-data service and completes the bank's required authentication. The provider receives allowed data through the applicable access arrangement. The customer should understand which party receives what information and how to stop future access.

Parties and roles

The customer may be an individual or business, with authority over the selected accounts. The account-servicing institution maintains the accounts. A third-party provider (TPP) delivers the requested service under its applicable authorisation or registration. Technical intermediaries can connect them but do not automatically acquire the right to use data for their own purpose.

European PSD2 terminology includes the payment service user (PSU), account servicing payment service provider (ASPSP), account information service provider (AISP) and payment initiation service provider (PISP). Do not apply those legal labels to every market. An e-money institution may service a payment account without being a deposit-taking bank.

Information, initiation and funds confirmation

Account information services access permitted account information. Payloads need explicit balance types, booking states, currency and freshness. A partner's calculated spending insight is not another authoritative bank balance. Scope and available history follow the applicable regime and permission.

Payment initiation requests the execution of a payment through the account-servicing provider. It does not create a new clearing or settlement system. Accepted, submitted, settled and beneficiary credited are different states. The provider's checkout must not declare final payment merely because an initiation endpoint acknowledged receipt.

Some regimes have a separate confirmation-of-funds service. Its purpose, eligible participants and response are distinct from an account-history read or payment initiation. One permitted role does not automatically authorise the others.

Consent, authentication and access are different

The service permission identifies scope and purpose. Authentication establishes assurance about the actor. API access checks enforce the actual request. Evidence should join the customer authority, provider, account, granted scope and requested action. Consent records and dashboard responsibilities are allocated differently across regimes; they do not universally sit in one bank-owned database.

A technical access token is not itself proof of current authority. Expiry, withdrawal, account eligibility and provider standing still matter. Conversely, consent withdrawn today does not automatically erase data lawfully retained under a separate applicable obligation. Retention and further use require their own analysis.

Payment permissions can cover a single instruction or an allowed recurring arrangement. The UK variable recurring payment standards illustrate a longer-lived permission for payments within agreed parameters. Do not teach that every PIS permission must be one-shot.

Operating and liability boundaries

The bank applies relevant validation, fraud, sanctions and execution controls to the payment. Their implementation can vary by channel and product while meeting applicable requirements. The parties need correlated references, errors, support routes and evidence for disputes. Recovery, returns and refunds are governed by the actual payment arrangement and law.

Liability does not universally switch from partner to bank at an acceptance timestamp. A dispute may concern authentication, unauthorised initiation, execution or misleading presentation, with different responsibilities. Preserve both parties' evidence and apply the relevant rules.

Worked example: budgeting is not permission to pay

In this fictional example, Sravanthi grants an app access to transaction information. The app later offers to move money into a savings goal. The original read permission does not establish authority for that payment. The new action needs the relevant provider role, account authority, permission and authentication under the arrangement.

Operations should be able to distinguish an authorised read from a payment request and explain the outcome. A successful connection test alone is insufficient evidence of either customer's instruction.

Sources and review questions

The EBA PSD2 rulebook, UK Open Banking standards and Australia's Consumer Data Right illustrate different frameworks. Identify the actual scope, eligible roles, security profile, permission lifecycle and dispute rules before implementation. A new policy proposal or standard is not automatically an obligation in every market.

Takeaway

Open banking joins a customer instruction to a permitted provider and a controlled interface. Information access, payment initiation, authentication and settlement remain separate concepts.

Continue to Open Finance.