Glossary

Open banking

Tokenization
left arrow icon

Replacing a sensitive value, such as a card number, with a substitute token that has no exploitable meaning outside the system that issued it.

When a card is added to a phone wallet, the device stores a token rather than the actual PAN. If the token is intercepted, it cannot be used elsewhere.

Tokenization reduces the scope of data a merchant must protect, since the real card number never reaches their systems.

Sandbox Environment
left arrow icon

An isolated test environment that replicates a bank's or provider's API, using fictitious data, so developers can build and test an integration without touching real accounts.

Under PSD2, banks must make a testing facility available to third parties before going live. A sandbox is also how a software company validates an integration after a bank changes its interface.

The term is also used for regulatory sandboxes, where a supervisor lets firms test innovative services under relaxed conditions. The two meanings are unrelated.

Fintech
left arrow icon

Financial technology: the use of software and digital infrastructure to deliver financial services, often by companies outside traditional banking.

It covers payments, lending, investment, insurance, accounting automation and the open banking infrastructure connecting them.

The term describes an approach rather than a sector: established banks run fintech products too, and the line between a fintech and a bank with good software has largely stopped being useful.

Embedded Finance
left arrow icon

Financial services offered inside a non-financial product, at the moment they are needed, rather than through a separate bank or provider.

Examples include paying in instalments at an online checkout, insurance offered during a booking, or an accounting tool that lets a business pay a supplier invoice without leaving the software.

Embedded finance is what BaaS infrastructure is generally used to build.

BaaS
left arrow icon

Banking as a Service: licensed banks providing their regulated infrastructure to non-banks, so that another company can offer accounts, cards or payments under its own brand.

The bank holds the licence and carries the regulatory obligations, while the partner owns the customer relationship and the interface. A retailer offering a branded card is usually doing so on a BaaS arrangement rather than holding a banking licence itself.

Data Portability
left arrow icon

The right of individuals to obtain their personal data in a structured, commonly used and machine-readable format, and to have it transferred to another provider.

In the EU it is established by the GDPR. Switzerland's revised Federal Act on Data Protection, in force since September 2023, introduced an equivalent right.

Applied to banking, data portability is the principle behind being able to take your transaction history with you when you change provider, rather than leaving it behind.

Consent Management
left arrow icon

The processes by which a customer grants, reviews and withdraws permission for a third party to access their financial data or initiate payments.

Consent must be explicit, limited to a defined scope and duration, and revocable at any time. Under PSD2 an access consent is time-limited and must be renewed, which is why aggregation connections periodically stop and require the customer to re-authenticate.

Good consent management means the customer can see at a glance who has access to what, and end it in one step.

Financial Data Aggregation
left arrow icon

Collecting and consolidating financial data from several banks or sources, usually through APIs, into a single view.

For a company with accounts at three banks, aggregation is what produces one consolidated cash position instead of three separate logins. It is the service an AISP licence permits, and the foundation on which cash management and accounting tools are built.

API Aggregator
left arrow icon

A provider that connects to many banks and exposes them through a single interface, so that a software company integrates once instead of bank by bank.

The aggregator absorbs the differences between institutions: varying API standards, authentication flows, data formats and coverage. Without one, supporting twenty banks means twenty integrations to build and maintain.

The trade-off is a dependency and a cost per connection, against the engineering effort saved.

Bank API
left arrow icon

An interface published by a bank that lets authorised external software query account data or submit payments directly, rather than through file transfer or a web portal.

In Switzerland, most bank APIs are reached through bLink, the SIX platform that standardises the connection, so a software provider integrates once rather than separately with each bank.

For accounting work, a bank API is what makes transactions appear automatically, where EBICS or camt.053 downloads require a file to be fetched and imported.

API
left arrow icon

An Application Programming Interface: a defined way for one piece of software to request data or actions from another, without a person in between.

An API sets out what can be asked, in what format, and what comes back. That contract is what allows systems built by different companies to work together reliably.

In finance, APIs are what replaced file downloads and manual re-entry: instead of exporting a statement and importing it elsewhere, one system queries another directly.

OBIE
left arrow icon

The body set up in 2016 by the UK Competition and Markets Authority to create open banking standards for the nine largest British banks.

It produced the Open Banking Standard, one of the first detailed API specifications of its kind, and influenced open banking design well beyond the UK.

OBIE was succeeded in 2022 by Open Banking Limited, which continues the work. The term still appears in older documentation.

RTS
left arrow icon

Regulatory Technical Standards: the detailed binding rules that specify how a piece of EU legislation must be applied in practice.

In open banking, the RTS on strong customer authentication and secure communication set out how SCA works, which exemptions exist, and what a bank's interface for third parties must do. They are drafted by the European Banking Authority and adopted by the Commission.

The distinction matters because the directive states the principle while the RTS determine what a provider actually has to build.

SCA
left arrow icon

Strong Customer Authentication: the PSD2 requirement that electronic payments and account access be confirmed with at least two independent factors.

The three categories are:

  • Knowledge: something only the user knows, such as a password or PIN.
  • Possession: something only the user has, such as a phone or card reader.
  • Inherence: something the user is, such as a fingerprint or face.

Two factors must come from different categories, which is why a password plus a security question does not qualify. Certain low-value or recurring payments are exempt.

PIS
left arrow icon

Payment Initiation Service: the regulated service, defined by PSD2, by which a third party initiates a payment on a customer's behalf, directly from their bank account.

Example: paying an online invoice straight from a bank account through a third-party application, rather than entering card details.

Providers: PISPs such as Tink, Token or TrueLayer.

The appeal is cost and speed: the payment travels on bank rails, so there is no card interchange fee, and the merchant sees the funds sooner.

PISP
left arrow icon

A Payment Initiation Service Provider: a third party licensed to initiate a payment directly from a customer's bank account, with their consent.

The customer authorises the payment in their own banking app, and the funds move by bank transfer rather than through a card network. Because no card scheme sits in the middle, fees are generally lower.

PISPs require a full payment institution licence, a heavier regime than the registration applying to AISPs, because they move money rather than only reading data.

AISP
left arrow icon

An Account Information Service Provider: a third party licensed to read a customer's bank account data, with their consent, but not to move money.

This is the licence behind account aggregation apps, budgeting tools and the automatic import of transactions into accounting software. Under PSD2 an AISP registers rather than holding a full payment institution licence, which is a lighter regime than that applying to PISPs.

TPP
left arrow icon

A Third Party Provider: a company authorised under PSD2 to access bank accounts on a customer's behalf, without being the bank holding the account.

TPPs fall into two licensed categories, which a provider may hold either or both of:

  • AISP: may read account information.
  • PISP: may initiate payments.

TPPs are supervised and must be authorised by a national regulator before they can connect to banks.

PSD2
left arrow icon

The EU Payment Services Directive 2, in force since 2018, which created the legal basis for open banking in Europe.

It obliges banks to give licensed third parties access to payment accounts with the customer's consent, introduced the AISP and PISP licence categories, and imposed strong customer authentication on electronic payments.

PSD2 does not apply in Switzerland, which is not an EU member. Swiss banks open their interfaces by commercial agreement rather than legal obligation.

What comes next: PSD2 is being replaced by a package of two texts, the PSD3 directive and the directly applicable Payment Services Regulation (PSR). Co-legislators reached political agreement in November 2025 and the parliamentary committee approved the texts in May 2026, but formal adoption and publication were still pending, so PSD2 remains the operative framework. Application is expected around 21 months after publication.

Open Finance
left arrow icon

The extension of open banking principles beyond payment accounts, to savings, pensions, insurance, mortgages and investments, so that a customer can authorise access to their full financial picture.

In the EU this is the aim of the proposed Financial Data Access framework (FiDA), still in negotiation. Open banking covers the current account; open finance would cover everything else.

Open Banking
left arrow icon

The practice of banks opening access to account data and payment initiation to licensed third parties, with the customer's explicit consent, through secure APIs.

In the EU it is mandated by PSD2: banks must give authorised providers access to payment accounts. Switzerland took a different route. There is no equivalent legal obligation, and access is market-led, developed through bLink, the SIX platform through which Swiss banks expose standardised interfaces to software providers.

For a fiduciary, the practical consequence is that bank data can flow automatically into accounting software instead of being downloaded and imported by hand.