Learn the different words and open banking terms commonly used across our documentation.



A financial account with a provider: for example, a current account.

account verification

A process that ensures only the bank account owner can authorise access to their account.

access token

A token that carries the necessary information to access a resource directly. When a client passes an access token to a server managing a resource, that server uses the information contained in the token to decide whether the client is authorised.

Access tokens usually expire after one hour, though this depends on the provider.


Account Information Services. Regulated providers (like TrueLayer) access a customer’s bank account data, so that the provider can offer services to that customer. They must have permission to do this.


Account Information Service Provider. A company authorised to access bank account data with the explicit consent of your user.

API-only method

The server-side integration to use if you want to build your own UI, integrate into your existing UI, or want more flexible customisation options.

App2App, app-to-app

Allows open banking-enabled services to offer a much simpler and faster authentication flow to users, via their mobile device.


Account Servicing Payment Service Provider. A company that provides and maintains a payment account for a payer.


A process in which a consumer logs in to online banking to create a secure connection between their bank and a third party provider.

authorisation flow, auth flow

A method by which a bank allows their users to authorise a payment. Right now we support redirect and embedded authorisation flows, but we may support more in the future.

authorisation server, auth server

The secure service hosted by TrueLayer that allows users to authenticate with their credentials. It also has API endpoints that you can use to obtain and renew an access_token.



The bank account that receives money when a payment is made.


Business Identifier Code. A number used to identify a specific bank as part of an international transaction. Also known as a “SWIFT code”.



A pair of .pem files — one public, one private — used to sign requests. These are also known as signing keys.


An application that implements our APIs.

closed-loop payment

With a closed-loop withdrawal, you can send funds to an account that your user has previously made a deposit from.


Information which identifies you or your user. This can include a username and password, API keys, a pair of certificates, etc.

consent flow

The online journey a user makes when they consent to a third party provider accessing their account information.

There are three types of consent flow in the UK & Europe:

consent parameters

The payment limits defined in the mandate.


Our developer portal, where you can get your client_id and client_secret, use our auth link builder, and get an access_token.


Data API

The TrueLayer product that provides access to your users' financial data.


embedded authorisation flow

An authorisation flow which requires you to present input fields to your user and submit their values to our API, to authorise a payment.


hosted payment page

A web UI that makes it easy to accept payments from your users.



This feature allows safe retries if a request fails (as long as the key is valid) while only performing the requested action once. Enabled using the idempotency-key header.


International Bank Account Number. A number that identifies a bank account, used for international transactions.



The agreement between you and your user which enables you to take payments from their account.

merchant dashboard

A tool that allows you to view reports about your incoming and outgoing payments, for internal monitoring or reporting purposes.

mobile SDK

Our software development kit for iOS and Android allows you to quickly add open banking payments to your app. Our mobile SDKs integrate with our Payments API.


oAuth 2.0

The industry standard authorisation protocol.

open banking

Open banking involves giving regulated companies secure, limited, authorised access to user bank accounts, so that those companies can provide useful services.

open banking payments

A way for your customers to pay using bank transfers from any provider that TrueLayer is connected with.

open-loop payment

With an open-loop withdrawal, you can send funds to any account. Useful for sending funds to your bank account, or to a user's account that hasn't previously been used to deposit funds.



A legacy payments product. Offers open-loop and closed-loop payments, verified payouts, merchant account access and automated sweeping.

Payments API v3

The latest version of our Payments API.

payment status

A value which indicates where a payment is in its life cycle.


An amount of money paid out to a person or group.


Payment Initiation Services. Gives regulated providers authorised access to a customer’s bank account to make payments on the customer’s behalf. The customer must give consent for this. See open banking payments.


Payment Initiation Service Provider. Initiates account-to-account payments with the explicit consent of the user.

private key

See certificates.


A bank or other financial institution that provides TrueLayer with access to financial data through APIs.

provider selection

A screen used by your users to select their bank. Use the providers endpoint to build this.


The second Payment Services Directive. European legislation which enables regulated third party providers (including TrueLayer) to access a user's bank account information and/or request payments, with the user's consent.


A Payment Services Provider. An entity that carries out regulated payment services.


Payment Service User. Any user who can make a payment through your customer interface is a PSU. In our documentation, PSU refers to your user.

public key

See certificates.

purchase categorisation

Using machine learning to automatically classify transactions from a given bank account into groups. For example, purchases can be sorted into utilities, work expenses, travel or groceries.


redirect authorisation flow

An authorisation flow which requires you to redirect your user to their bank's website or app to authorise a payment.

redirect URI

Also known as a return URI. When initiating a payment with the redirect authorisation flow, this is the page that the user will be redirected to, usually your app or website, after they have authorised a payment with their bank.

redirect URL

Only used in iOS payments. When initiating a payment with the redirect authorisation flow, this is the page that the user will be redirected to, usually your app or website, after they have authorised a payment with their bank.

refresh token

A token you need to get a new access token. Usually used to get a new access token after the previous one has expired, or to get access to a new resource for the first time.

Refresh tokens expire until the user needs to reconfirm consent (usually after 90 days). If not used, they expire after 30 days.


The bank account which makes a payment. This is usually your user's bank account.

return URI

When initiating a payment with the redirect authorisation flow, this is the page that the user will be redirected to, usually your app or website, after they have authorised a payment with their bank. Also known as a redirect URI.



A testing environment in which you can test your integration without using live bank accounts.


Strong Customer Authentication. A security requirement introduced to cut down on payment fraud online. It requires that all digital payments must go through an authentication process that proves the payer is who they say they are and is authorised to use the account.

In this process, the user must confirm two of three criteria:

  • something only the user knows (eg a password)
  • something only the user possesses (eg their phone via their mobile phone number)
  • something the user is or has (eg via touch or Face ID).


Sort Code and Account Number. Bank details used to identify accounts in the UK and Ireland.


A set of permissions that the user grants to the client so that the client can access data on their behalf.


Our product which simplifies onboarding by allowing a user to register with a single payment.


Society for Worldwide Interbank Financial Telecommunication. An organisation that facilitates international payments and assigns Business Identifier Codes (BICs), also known as “SWIFT codes”.


third party provider

Account information and payment initiation service providers that are authorised by the FCA.

transaction categorisation

See purchase categorisation.



Your customer. See PSU.


variable recurring payments (VRP)

Enables third party providers like TrueLayer to make payments on behalf of a user at variable amounts and intervals. The user gives consent, sets limits for these payments and authenticates the payment mandate with their bank upfront. Payments are then initiated automatically on a regular basis.

Verification API

Our product that verifies a user by comparing your customer's name with bank records, then assigning a match_score.

VRP commercial

Variable recurring payments (VRPs) made between consumers and businesses.

VRP sweeping

A type of variable recurring payment (VRP) enabled by a legal provision called sweeping, which enables some third party providers to make payments between accounts owned by the same user.