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.


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

A flow where the user authorises a payment or connection in their banking app, rather than a webpage.


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 (eg provider selection, then scheme selection, bank login and redirect to merchant). Currently, 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. For pay-ins, the beneficiary is your account.


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.


The Clearing House Automated Payments System. Typically used for high-value payments such as corporate payments, foreign exchange, property, and car purchases.


An application that implements our APIs.

closed-loop payout

Paying into the same account that your user has previously made a payment 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 and Europe:


The payment limits defined in a mandate.


Our developer portal, where you can get your client credentials, build an auth link, customise your auth UI and manage transactions.


Data API

Provides access to your users' financial data.


embedded authorisation flow

An authorisation flow in which your user inputs their credentials and submits them to our API to authorise a payment (rather than being redirected to their bank login page).


Faster Payments

The payment scheme that all TrueLayer payments are made through in the UK. It's free, and Faster Payments payments are instant.


hosted payment page

An out-of-the-box web UI that makes it easy to accept payments from your users, including all the screens you need to accept payments across Europe.



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 and payments in Europe.



An agreement between a business and a user, that enables the business to take payments from the user's account. No additional consent is required from the user for each payment, if they agreed to the initial mandate. Mandates have constraints on the allowed frequency and value of payments.

merchant account

A bank account created and managed for you by TrueLayer. Required to make payouts or refunds with the Payments API, and we recommend creating one per currency you accept payments in.

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, with all the features of the hosted payment page. 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 by bank transfer from any bank account that TrueLayer is connected with.

open-loop payout

A payout to an account that hasn't already paid you. 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 lifecycle (for example: being authorised by the user, failed, or successfully settled).


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 in the authorisation flow where your users select the bank they want to pay from. You can use


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.


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.

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

When initiating a payment with the redirect authorisation flow, this redirects the user back to your app or website after they have authorised a payment with their bank.

redirect URL

The URL that you send to us when initiating a payment with the redirect authorisation flow, if you are using the iOS SDK. Used to redirect the user back to your application or website after they have authorised a payment with their bank. Can be set in Console > Settings > Allowed redirect URIs.

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

See redirect URI.



A testing environment where 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).

SEPA Credit

A payment scheme supported by all providers in Europe. Payments made on this scheme take 1–2 business days, sometimes up to 3. Most providers do not charge to use this scheme.

SEPA Instant

Short for SEPA Instant Credit Transfer. A payment scheme supported by some providers in Europe. For high-value, time-critical payments, we recommend using this scheme. Most providers charge a fee to use this scheme.


A payment scheme is the infrastructure that allows you to transfer money digitally from account to account.


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 (the person who is paying you, or that you are paying out to). See PSU.

user object

The object within a payment creation request that enables you to


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.

commercial VRP

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

sweeping VRP

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.