Appendices

Common Terminology – Preferred Terms and Language

This version is:

This is the latest version Published 5 months ago 28 Jun 2024

This document is based on existing research undertaken by Open Banking ltd (OBL) over the last 4 years, a detailed audit of existing language used in the market, work undertaken on the naming of dashboards undertaken in early 2021 and an interactive workshop held in June 2021 with a range of participants including ASPSPs, TPPs and consumer experts.

Other pages in this section

Introduction

The purpose of this document is to set out a series of preferred terms and terms to avoid by participants when describing open banking to consumers. We have identified two main language issues in the market:

The use of jargon or complex terms. In particular, we have seen some legal terms which are being used in customer-facing language.
The use of inconsistent terms across the market. Given that open banking involves being passed from one entity to another and back again, it is clearly helpful if consistent language is used during that journey. More broadly, it is helpful in terms of familiarity and comprehension if the same terms are used across the ecosystem.

We have seen the value of simplifying language and bringing consistency in other financial services markets, such as the pensions market which has made significant progress in eliminating unhelpful jargon and bringing greater consistency.

This introductory quote from the NEST work on pensions language could equally apply to open banking:

Words alone are rarely enough to change behaviour, especially when the change is needed on a national scale. It’s relatively easy to persuade someone that saving for retirement is a good idea – provided you can gain their attention in an ever-noisier communications environment. Yet decades of industry experience and academic studies have shown that it’s quite another matter to translate this good intention into action. The behavioural biases that stand in the way of retirement saving are well-known and they can be much more powerful than any positive intention to save.^[1]Beyond the Defaults, 2020. See here

This document is based on existing research undertaken by Open Banking Ltd (OBL) over the last 4 years, a detailed audit of existing language used in the market, work undertaken on the naming of dashboards undertaken in early 2021 and an interactive workshop held in June 2021 with a range of participants including ASPSPs, TPPs and consumer experts.

This document is intended as guidance and following its recommendations is recommended but optional for participants.

[1] Beyond the Defaults, 2020. See here

Language Principles

In developing this language guide, we have used the following principles, developed and agreed with the Expert Advisory Group which met during May and June 2021

OBL is committed to demystifying jargon to enable consumers and businesses to understand what open banking is.
We want to use simple to understand and transparent language direct with consumers and businesses, so they fully appreciate what it means for them to share their account information and are able to move, manage and make the most of their money, or to make account-to-account bank transfers.
We commit to reviewing all existing terminology related to open banking standards and where appropriate will come up with recommended new simple phrases to explain them.
With regards to all future open banking implementation, we commit to ensuring all language is designed with a ‘consumer-first’ lens.
We will work with all stakeholders to encourage the use of jargon-free language when explaining open banking-enabled products and services.
We will only use technical terms and acronyms where absolutely necessary, and this will typically be for communications between open banking companies rather than in consumer-facing communications

Recommended Language – Data Sharing Journeys

Area	Recommended Terms	Terms to Avoid	Guidance on Use and Examples
Customer facing term for ASPSP	Bank, Account Provider	Provider, Account	In the TPP domain, this language was not reported to cause significant difficulties given that other contextual information is available (for example the list of organisations to which the customer can connect to). It would be clear to most customers that they can connect to a range of organisations and “bank” as a shorthand for a range of different types of providers not all of whom were technically banks. Whilst some companies use “account” (eg, “please select an account to add”), it has been highlighted that in many consent journeys, a customer may select multiple accounts from the same organisation and therefore it is preferable to refer to the organisation itself. The challenge is greater in General Communications where there is a need for a general term covering all types of ASPSPs. Using “bank” in this context would clearly significantly understate the potential of open banking. In these contexts, “account provider” is the preferred term, but with an additional explanation that this includes current accounts, credit cards and certain savings accounts. In OBIE research, consumers were comfortable with the term “account provider”^[2]Open Banking API Report – July 2018, Ipsos , but “provider” is insufficiently granular and clear Do: “Please select your bank from the list below” “Please select your account provider” “These are the account providers we are getting data from” “Open banking allows you to share data from a range of account providers, such as current accounts, credit cards and savings” Avoid: “Please select your provider from the list below” “Please select an account to add”
Customer facing name for relationship between TPP and ASPSP	Connections / Connect	Access	Whilst the technical legal language refers to access to payment accounts, it has been found in research by a number of participants that the phrase “access” is confusing to consumers. It has connotations of account takeover and can give the false impression that a TPP has control over an account. It also feels in conflict with terms and conditions which require customers to not give access to their account to anyone else^[3]For example, “If you think someone has used or is able to use any of the ways of accessing to your account, you must tell us as soon as you can” – Barclays Terms and Conditions for Personal … Continue reading. The term “connections” is strongly favoured by the expert groups which OBIE has convened. This term is consistent with the term also used in the preferred naming for Access and Consent Dashboards, which are now recommended to be referred to as Open banking connections. It is already commonly used by TPPs in the market, although some refer to “link” or “linked”, a term which is not preferred, although is not defined as a term to avoid. The term to be avoided is “access”, for the reasons given above. This is the legal term and is unclear and unhelpful in a customer-facing context Do: “Which bank would you like to connect to?” “Connect account” “Success. You are now connected” “These are the accounts you have connected” “Refresh connection by [date]” Avoid: “Please select the bank you would like to grant us access to” “Please give us permission to access the following information” “Success – we now have access to your account” “Open banking is a secure way to allow providers to access your account”
Customer facing term for how data moves between ASPSP and TPP	Share	Access	Whilst the overall term for the relationship between TPP and ASPSP is “connect” or “connection”, there is also a need for the term used to describe the way that data moves from one to the other. The strongest and clearest term for this is “share” or “sharing”. Data sharing is emerging as a general term in consumer use. Participants in the expert sessions convened by OBIE had a very strong preference for the term sharing, even though the phrase “access” remains in quite widespread use. As discussed above, access is unclear and has connotations of account takeover. In research, participants reported that access performed badly and suggested that the TPP could in some way take over the consumer’s account. It was also particularly disliked by consumers who had been victims of fraud. In contrast, “data sharing” was relatively well understood. Do: “You are agreeing to sharing the following data with [TPP]” “Account you wish to share from” “You can stop sharing your data at any time” “These are the service providers you are your sharing data with” “Open banking is a secure way to share data from your bank account with other apps and websites” Avoid: “Select the account you wish to grant access to” “[TPP] would like access to the following account” “Open banking is a secure way to grant access to information from your bank account”
Customer facing term for the material shared from ASPSP to TPP	Data, Account Data, Account Information	Financial Data, Information	There is a wide range of terms in use today across the ecosystem to translate the legal concept of “account information” into clear, consumer friendly terms. Our expert group was not able to select a definitive term and it is likely that a range of terms could be used, with contextual information helping to clarify. We encourage the use of the term data over information. Certainly “information” alone is not clear enough and could mean that some consumers remain unclear about exactly what is being shared from the ASPSP to the TPP. This has been confirmed in research by some participants who found it to be unclear. We, therefore, suggest avoiding the term “information” unless it has some other qualifying statement (such as “account information”) The term data has a number of arguments in its favour: we already have a term defined for the data clusters; and given our preference for the term “sharing”, data fits comfortably with this. Do: “This is the data you will be sharing” “[TPP] is requesting the following account information from your bank” “For you to use this service, we need to get your account information from [your bank]” “Data you will share with [TPP]” Avoid: “We are requesting access to the information from your account” “This is the information we are sharing” “Open banking allows you to share information from your bank account”
Customer facing name for redirection	Securely Transfer	Redirect	The phrase redirect is a technical phrase that is used in consumer-facing material and is likely to cause confusion. It should be avoided. Redirection can have associations with errors on websites or even phishing attacks. The obvious alternative, and the one favoured by many participants, was “securely transfer”. This was most important in the TPP domain, given that the process is explained by the TPP prior to securely transferring the customer to their ASPSP. It is also used by ASPSPs after consent. Some participants favoured more conversational terms, such as “returning you to [TPP]”. We do not suggest avoiding these terms but favour the clearer, and the more reassuring term “securely transferring” The preference for “securely transferring” was confirmed in OBIE Research (“Securely transferring you’ feels more reassuring.”)^[4]OBIE Language Research 2017 Do: “To complete this connection, we will securely transfer you to [ASPSP]” “Securely transferring you to [ASPSP] now” “To set up an open banking connection, you are securely transferred to your account provider to authenticate” Avoid: “We are redirecting you to [ASPSP]” “To set up an open banking connection, you will be redirected to your account provider to authenticate”
Customer facing term for undertaking SCA	Verify, Authenticate	None	Many ASPSPs have their own terms or ways of describing this process and there are clear benefits in the open banking authentication experience being as close as possible to the rest of the ASPSP’s digital experience. For this reason, we are not setting out terms to avoid. Despite the strongest preference being for “log in”, which is the phrase that probably makes the most sense to consumers, many ASPSPs pointed out that the consumer is not actually logging into their bank, they are merely authenticating to share their data Verify was a reasonable alternative. Authenticate was felt to be quite a technical term, but provided that it was explained when first used it was acceptable Do: “To start sharing this data we will securely transfer you to [ASPSP] so that you can authenticate” “Before you can start sharing data with open banking you have to authenticate with your bank.” “You will now authenticate by providing your security details” (with additional explanation) Avoid: “We are securely transferring you to [ASPSP] so you can authenticate” (without explanation)

Recommended Language – Payment Journeys

Area	Recommended Terms	Terms to Avoid	Guidance on Use and Examples
Customer facing term for Payment Initiation (TPP Space)	Pay / Transfer / Donate (Use Case Specific)	Initiate a Payment, Permission to Make a Payment	Whilst a Payment Initiation journey has some very specific technical features, where a consumer provides consent for a PISP to initiate a payment on their behalf, in language terms simplicity is preferred – wherever there are no legal constraints. Therefore the preferred term (when setting up a payment in the TPP domain) is “Pay”, “Transfer” or “Donate” – in other words, a simple term setting out the action that the consumer is taking. The technical detail that this is payment initiation should not be displayed to the consumer unless there is a specific legal reason why a provider is required to. The phrase “payment initiation” should be avoided wherever possible along with other similar alternatives such as “permission to make a payment”. This is supported in research, where consumers couldn’t easily see the difference between open banking payments and other types of payment: “To be honest, I couldn’t tell any difference between this and what I normally do when I’m shopping online”^[5]Verbatim from Open Banking Consent Research 2017. The phrase “payment initiation” was “not clearly understood”^[6]OBIE Language Research, 2017 Do: “Click ‘Agree’ to pay” “Make payment” “To transfer funds into your account, click Agree” “We need your permission to make this payment “We will securely transfer to your bank to make the payment / transfer / donation” “Add money to your account” “Open banking payments are a simple, secure way to pay without having to enter the payment details yourself. This makes it quicker and helps to reduce errors” Avoid: “By clicking continue, I consent to the initiation of this payment from my bank account” “You are giving permission to [TPP] to initiate a payment on your behalf” “Open banking payments allow you to instruct a website or app to initiate a payment from your account with your explicit consent”
Customer facing term to explain the payment (ASPSP space)	Pay	Initiate a payment, Set up a payment	As in the TPP domain, in the ASPSP domain simple clear language works best and customers do not need to know the detail of what happens behind the scenes. The preferred language therefore, as in the TPP domain, is “pay”. References to “initiation” should be avoided All providers must undertake their own legal review of language. One specific issue was highlighted by some providers, which is the language on the ‘call to action’ button once the payment order is complete. There was a preference to using language such as “Pay Now” on the call to action, but providers found it challenging legally. Therefore many have opted for language such as “Continue” or “Proceed”. Whilst clearer language is always preferred (particularly when this is a ‘point of no return’ on the payment), legal obstacles also need to be considered It is worth noting that in OBIE research consumers preferred “Confirm” to “Pay Now” as the call to action^[7]“Confirm was more universally liked than Pay now, and felt more appropriate versus allow (although the were relatively interchangeable, and each made clear what was occurring)” – Consent … Continue reading Providers must ensure that it is clearly explained to the customer that they have reached the point of payment and will not get another chance to review or change their mind. Contextual information can be used to clarify this if it is not possible to use terms such as “Pay Now” on the call to action button Do: “Choose an account to pay from” “Which account would you like to pay from” Avoid: “Choose an account to set up a payment from” “[TPP] would like to initiate a payment from your account”
Term to describe the exemption that will be used for payments	To, Where we are sending money	Payee	Payee is quite technical language and should be used with care, and ensuring that it is clear what it refers to from the context. We recommend using language which is much easier to understand, such as “where we are sending money”. Depending on context, it may be sufficient to simply use language of “to”.

Recommended Language – Consent Dashboards

Area	Recommended Terms	Terms to Avoid	Guidance on Use and Examples
Customer facing term for consent dashboard	Open banking connections, Open banking connected accounts	Consent dashboard	This term has already been defined, based on research conducted in 2020 and the expert input of a range of participants. There are a wide range of terms in use in the market and moving to a common naming will help consumers manage their open banking data sharing and build trust in the market.
Date Consent Granted	Date connected, first connected	Date access granted	Participants consulted during the consultation process strongly favoured the simplicity of “Date connected” or “first connected” which is consistent with the overall naming of dashboards. Whilst the technical legal agreement is that the consumer has consented to allow a TPP to access their payment account, references to “access” should be avoided
Date / time TPP obtained data from the ASPSP	Date / time updated, Last updated	Last synced, date refreshed	Many TPP dashboards include information on when they have last updated transactions and balances from the ASPSP. This is important as it ensures that customers know whether they are looking at up to date information such as their balance There can be confusion between whether data has been updated, or whether a connection has been updated. For this reason, we advice the simplicity of “Date / time updated”. This could be in the form of “Updated x seconds ago”. Other terms risk confusing customers and “last synced” and “date refreshed” should be avoided for this reason. Note, we have not defined recommended terms for reauthentication or reconsent because of expected changes from the FCA in response to consultation CP21/3.
Revocation of consent	Disconnect, stop connection, remove connection	Revoke consent, revoke, delete account	In line with the recommended language for dashboards, in consultation there was a strong preference for language relating to “connections” – either “disconnect”, “stop connections” or “remove connection” Terms such as “revoke consent” or “revoke” are not recommended as the language is too technical for most consumers. We also do not recommend “Delete account” as it could easily cause confusion and lead consumers to believe they are potentially deleting their bank account

Recommended Language – Access Dashboards

Area	Recommended Terms	Terms to Avoid	Guidance on Use and Examples
Customer facing term for access dashboard	Open banking connections	Access dashboard, Permissions	This term has already been defined, based on research conducted in 2020 and the expert input of a range of participants. There are a wide range of terms in use in the market and moving to a common naming will help consumers manage their open banking data sharing and build trust in the market.
Term to describe the items on an access dashboard	Connections	Consents, agreements	Participants consulted during the consultation process strongly favoured the simplicity of “Connections”, which is consistent with the overall naming of dashboards. Terms such as consents were too technical and therefore not recommended. Agreements was not precise enough and also not recommended.
Customer facing term for TPPs	”Service providers”, “apps and websites”	”Third parties”	The experts consulted were not able to define recommended language for this important term and there were a wide range of views expressed. Several participants had undertaken research which highlighted that the term “third parties” caused significant confusion for consumers: it is a legal term and has connotations of another party who can access data (a customer would logically think that a third party is another party, who is neither the ASPSP nor the TPP). OBIE undertook research with 1,000 end consumers in Summer 2021^[8]Language Testing, July 2021, Marketing Means. 1,021 online interviews., which confirmed that “third parties” was not a term that resonated well with consumers. It was scored as relatively clear (3rd of the 5 terms tested), but it caused the most concern of the 5 terms researched. Examples of verbatims from the research included: “Third parties makes me believe that my personal data/info could be shared with anyone”, “It will make me receive more spams”, “It's vague and given the number of scams occurring at the moment”, “It has connotations of data being used for advertising.” The two terms which researched best were “service providers” and “apps and websites” and we therefore recommend these two terms, with the addition of the word “regulated” in contexts where consumers need additional reassurance.
Revocation of access	Stop sharing	Cancel access, remove access, remove connection	In line with the recommended language to describe the way that data moves from ASPSP to TPP (sharing), there was strong support for the use of the simple language “stop sharing” by ASPSP More technical language using terms such as “revoke” and “access” was not favoured. Nor was the use of the term “connection” in this context
Reconfirmation of consent	Reconfirm, reconfirmation	Reconsent	Following the FCA Policy Announcement, TPPs seeking to reconfirm consent with their customers should use the language of reconfirm or reconfirmation. This was supported in discussion at the Expert Advisory Group held in Q1 2022 and including a range of TPPs, ASPSPs and End User Representatives. Do: “Please reconfirm your consent” “If you wish to continue allowing us to get data from [ASPSP], please review and reconfirm the consent" Avoid: “Please reconsent” “After 90 days you will need to reconsent”

Recommended Language – Variable Recurring Payments (VRPs)

Area	Recommended Terms	Terms to Avoid	Guidance on Use and Examples
Term to describe consent parameters	Payment rules	Consent parameters	Technically, consent parameters is a useful industry phrase to explain the set of rules which are agreed when a VRP is set up, but it is a challenging term for consumers to understand We recommend the use of the phrase “payment rules”, which is intuitive and simple for consumers. This is particularly important as the concept of setting payment rules is a new, but valuable, control tool for consumers that no other form of payment typically provides.
Term to describe this form of payment	Payment permission, Variable Recurring Payment	VRP	There is not an ideal term to describe a Variable Recurring Payment to a consumer and we, therefore, recommend that clear explanations are used to help consumers understand what they are setting up. This could be via information bubbles or FAQ guides. In a VRP setup journey, we recommend using the full term “Variable Recurring Payment”. Until the term is established we do not recommend using the abbreviation VRP. On a dashboard, providers can choose whether to use Variable Recurring Payment Permissions or abbreviate to Payment Permissions. In this context, the phrase “Payment Permissions” will be clear to most consumers, although explanatory text will still be required. Do: “You have given us payment permissions for these accounts” (PISP VRP Access Dashboard) “Cancel payment permission” “Permission from [date] to [date]” “Tap manage to view more detail or cancel the permission” “Permission cancelled” “Setup Variable Recurring Payment” Avoid: “You are setting up a VRP” “This VRP will continue until [date]” “Set up VRP Consent”
Term to describe the exemption that will be used for payments	Payee List, Send Money To	Trusted Beneficiaries	It is important as part of the VRP Setup process that the customer is informed that the VRP beneficiary will be set up as a trusted beneficiary – however, we do not recommend using this language which is a technical industry term We recommend that participants mirror language already in use in their online channels to describe trusted beneficiaries, likely to be “payee list” or a similar term.

Note: Whilst the SWIFT BIC is required to route the payments, for payments in Euro the customer does not have to provide this, the sending bank must derive it from the beneficiary IBAN

Transaction Risk Indicators (TRI) definitions and guidance Previous

Common Error Scenarios – Preferred Status and Reasons Next

References[+]

References
↑1	Beyond the Defaults, 2020. See here
↑2	Open Banking API Report – July 2018, Ipsos
↑3	For example, “If you think someone has used or is able to use any of the ways of accessing to your account, you must tell us as soon as you can” – Barclays Terms and Conditions for Personal Customers. Also in general advice to consumers to prevent fraud: “Whether it's your email, social media or some other type of online service, there are many things which can alert you to the fact that someone else is accessing your account” – National Cyber Security Centre
↑4	OBIE Language Research 2017
↑5	Verbatim from Open Banking Consent Research 2017
↑6	OBIE Language Research, 2017
↑7	“Confirm was more universally liked than Pay now, and felt more appropriate versus allow (although the were relatively interchangeable, and each made clear what was occurring)” – Consent Research 2017
↑8	Language Testing, July 2021, Marketing Means. 1,021 online interviews.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.