Transaction Risk Indicators (TRI) definitions and guidance

Overview

A number of risk indicators are included in the Standards under the Risk section of each API. This enables the TPPs to provide additional granular information about their operational model and context to the payment that is being initiated.

This guidance intends to ensure there is a common understanding of the various risk indicators defined in the Standards and to enable the TPPs and ASPSPs to interpret the risk indicators consistently.

Payment Purpose Codes (PPC)

Definition:

As per ISO 20022 definition, this is the underlying reason for the payment transaction.

The Purpose codes are four-letter codes which carried across the payment chain providing information to all users in the payment chain for the payment types that support ISO 20022.

Usage:

Payment Purpose code is used by the end-customers, initiating party, (ultimate) debtor, and (ultimate) creditor to understand the nature of the payment. The Standards enable the usage of the full list of PPCs as per ISO 20022. This enables the TPPs and ASPSPs to align with ISO 20022 and benefit from any additions that are done periodically.  

However, the Bank of England has published a UK-recommended Purpose Code list which is a subset of the full ISO list. The aim of this is to increase usability by identifying the common codes that are applicable in the majority of the transactions for UK–originated domestic transactions. For International payments, all codes in the full list must be supported by all the participants.

OBL also encourages and recommends taking guidance from the shorter UK recommended list but also recommends the participants to use and support any appropriate PPC from the full list if it is closer to their purpose. We will provide a collated version of the ISO External Code list in the Standards and update it periodically.

Note: As mandated for CHAPS, PPC is required to be provided for property transactions and payments between two financial institutions. For Property transactions, the PISP needs to ensure that the appropriate codes are always provided.

We also take reference from the Purpose code consultation done by the Bank of England which suggests the ‘OTHR’ purpose code should not be included in the UK Purpose Code List because of its broad scope and risk to the overall data quality of PPC.  However it is a recommendation to avoid if a better match is available and not use as a default option.

https://www.bankofengland.co.uk/paper/2024/policy-statement/mandating-iso-20022-enhanced-data-in-chaps

Some additional clarification on usage of below PPCs, to help with implementation:

• The code EPAY (“Transaction is related to e-Payment”) should only be used for transactions where the customer is loading a wallet. Our definition of a wallet is “an account which stores value but which does not have a Sort Code and Account Number. Examples could include PayPal, gaming wallets, gambling wallets or crypto wallets”.
• The code GDSV could potentially cover a wide range of purchase transactions (“Transaction is related to purchase and sale of goods and services”). Please explore if there is a more precise category before using this code.
• INTP is likely to be a commonly used code (“Transaction is a payment between two accounts belonging to the same party (intra-party payment), where party is a natural person (identified by a private ID, not organisation ID).”). This should only be used for payments to an account with its own Sort Code and Account Number. There are other codes for other types of Me-to-Me transactions such as SAVG, INVS, PEFS, CDBL.
• IVPT (“Transaction is the payment for invoices”) and SUPP (“Transaction is related to a payment to a supplier”) could both be relevant for business payments. If the payment relates to an invoice (either in advance or arrears) use IVPT. For other payments without an invoice use SUPP.
• INSM (“Transaction is related to a payment of an instalment”) includes all types of instalment payments, including Buy Now Pay Later.
• TCSC (“Transaction is related to a payment associated with charges levied by a town council”) refers to Council Tax.
• INVS (“Transaction is for the payment of mutual funds, investment products and shares.”) Includes payments into unit trusts, investment platforms, Stocks and Shares ISAs, stockbroker accounts. Cash ISAs are considered savings accounts and should be recorded under SAVG.
• CDBL (“Transaction is related to a payment of credit card bill.”) also includes payments to charge cards.

Category Purpose Codes (CPC)

Definition:

As per ISO 20022 definition, category purpose code specifies the high-level purpose of the instruction based on a set of pre-defined categories.

The Category Purpose codes are four-letter codes which are carried across the payment chain providing information to all intermediate agents in the payment chain for the payment types that support ISO 20022.

Usage:

This is used by the initiating party to provide information concerning the processing of the payment. It could trigger special processing by any of the agents involved in the payment chain. The Standards enable the usage of the full list of CPC as per ISO 20022. This enables the TPPs and ASPSPs to align with ISO 20022 and benefit from any additions that are done from time to time.

However, the Bank of England has published a UK-recommended Category Code list which is a subset of the full ISO list. The aim of this is to increase usability by identifying the common ones that are applicable in the majority of the transactions for UK–originated Domestic transactions. For International payments, all codes in the full list must be supported by all the participants.

OBL also recommends taking guidance from the shorter UK recommended list but also recommends the participants to use and support any appropriate CPC from the full list if it is closer to their purpose even if there may not be a mechanism in place to send the information to the receiving ASPSP for some payment types. We will provide a collated version of the ISO External Code list in the Standards and update it from time to time.

Payment Context Codes (PCC)

Definition:

The Payment Context Code is an OBL proprietary risk indicator that was introduced to provide insight to ASPSPs and give further context about the relationship that the PISP might have with the beneficiary of funds whom they provide service either directly or indirectly. All PCCs are defined in detail below.

4.1 TransferToSelf

Definition:

Transfer to Self is an indicator that the transaction is between two accounts belonging to the same person or legal entity.

Usage:

The PISP must attest and use the code if the transaction fulfils the following criteria: when the transaction is between two accounts where both the accounts have a Sort code and Account Number (SCAN) and where both the accounts belong to the same person or legal entity.

Note: The PISP must have a direct contract with the PSU who is the ultimate beneficiary. Hence Contract present indicator (CPI) must be ‘yes’.

Examples:

Customer moving funds between their own accounts at the same or different financial institution.

4.2 FaceToFacePointofSale

Definition:

Face To Face Point of Sale is to indicate that the customer (PSU) is present and initiating the payment themselves at the point of sale.

Usage:

The PISP must attest and use the code if the customer (PSU) is present either physically in the store and making a purchase and payment to a business or charity.

The PISP could have a contractual relationship with the ultimate beneficiary (Merchant) for the provision of open banking payment acceptance services.

Examples:

Retail Payment – A Person buying goods or services in person.

A business person making online purchases.

A Person or Business paying a charity organisation either online or at the point of sale.

Note: Selecting this PCC implicitly means that it is also a Transfer to Third party, however for clarity where the payment fulfils the above criteria it should be recorded as FaceToFacePointofSale.

4.3 EcommerceMerchantInitiatedPayment

Definition:

E-commerce Merchant Initiated Payment indicates that the customer (PSU) is making a payment using the merchant’s customer-facing website or app which has an integrated checkout feature to make a payment.

Usage:

The PISP must attest and use the code if the customer (PSU) has made payment using the merchant’s customer-facing website or app where there is an integrated checkout and the PISP is providing services to the Merchant.

The PISP may or may not have a contractual relationship with the merchant who is the beneficiary of the payment.

The PISP may be the Merchant themselves.

The PISP may be providing open banking PISP services to a party and is indirectly providing services to the Merchant.

Examples:

A person-to-business customer making a purchase of goods and services or paying a charity or paying bills, taxes, pension, mortgage, or credit card bill using an integrated checkout service where open banking payment is an option. This could also be a cVRP setup by the merchant to make regular payments where the customer (PSU) may not be present for each individual payment.

 Note: Selecting this PCC implicitly means that it is also a Transfer to Third party, however for clarity where the payment fulfils this criteria it should be recorded as EcommerceMerchantInitiatedPayment.

4.4 BillingGoodsAndServicesInAdvance

Definition:

Billing Goods And Services In Advance is to indicate that the transaction relates to an invoice which has been generated and issued to the customer (PSU) in advance of goods or services being provided by the merchant.

Usage:

The PISP must attest and use the code if the payment is made in advance against an invoice issued by the merchant (who is the ultimate beneficiary) to the customer (PSU). The PISP could use the structured remittance information to provide the invoice information in a structured way in addition to the payment purpose code “GDSV” to support.

Category should be determined according to a reasonable assessment of the predominant merchant charging model, for example where a business operates invoice in advance and invoice in arrears, the PCC should reflect the predominant way in which open banking is used.

Selecting this PCC implicitly means that it is also a Transfer to Third party, however for clarity where the payment fulfils the above criteria it should be recorded as BillingGoodsAndServicesInAdvance.

Examples:

Advance payment for broadband / mobile services, a deposit to cover the seller’s out-of-pocket costs for supplying the service e.g., producing bespoke furniture.

4.5 BillingGoodsAnd ServicesInArrears

Definition:

Billing Goods And Services In Arrears is to indicate that the transaction relates to an invoice which has been generated and issued to the customer (PSU) after goods or services have been provided by the merchant.

Usage:

The PISP must attest and use the code if the payment is made against an invoice issued by the merchant (who is the ultimate beneficiary) to the customer (PSU) after providing the goods and services. The PISP could use the structured remittance information to provide the invoice information in a structured way in addition to the payment purpose code “GDSV” to support the transaction risk information.

The category should be determined according to a reasonable assessment of the predominant merchant charging model, for example where a business operates an invoice in arrears.

Selecting this PCC implicitly means that it is also a Transfer to a Third party, however for clarity where the payment fulfils this criteria, it should be recorded as BillingGoodsAndServicesInArrears.

Examples:

Professional services billing, builders merchant which invoices monthly in arrears

4.6 TransferToThirdParty

Definition:

Transfer to a Third Party is to indicate that the transaction is between two accounts belonging to two different persons or legal entities. The accounts could be at the same financial institution or different.

Usage:

The PISP must attest and use the code if the transaction is between two accounts where both the accounts have a Sort code and Account Number (SCAN) and where both the accounts belong to different persons or one of them is a legal entity. This is a preferred PCC if there is no contractual relationship between the PISP and the beneficiary account holder to provide a service of which this transaction might be an outcome.

Note: If another PCC provides better context or more detail which will help ASPSPs to understand the nature of the relationship between the PISP and the Beneficiary, other codes should be used (ie, FaceToFacePointofSale, EcommerceMerchantInitiatedPayment, BillingGoodsAndServicesInAdvance or BillingGoodsAndServicesInArrears).

Examples:

A Person to Person (P2P), Person to Business (P2B), Business to Business (B2B) or a Business to Person (B2P) transaction all are examples of Transfer to Third Party.

Contract Present Indicator (CPI)

Definition:

The Contract Present Indicator is a OBL proprietary risk indicator that is introduced to provide insight to the ASPSPs and give further context of whether there is a contractual relationship between the PISP and the beneficiary of funds to whom they provide a service either directly or indirectly.  This is a binary yes/no indicator to indicate whether the PISP has a contractual relationship with the merchant (directly or indirectly) who is the beneficiary of the funds. Each of the following conditions are required to be met before the PISP can attest ‘yes’ to the CPI.

1. Contractual arrangement –
   • Direct relationship – When the PISP has a written bilateral agreement with the beneficiary who is selling goods or services to their customers but using the PISP’s open banking services.

1. • Indirect relationship – When the PISP could be in a reseller model, where they do not have a direct contractual agreement with the beneficiary but there is an equivalent sub-contract in place in any chain between the PISP and the first beneficiary and then between the first and next/ultimate beneficiary in the chain.
   • Internal – In cases where the beneficiary is part of the same legal entity as the PISP.
2. Customer due diligence – The PISP must apply customer due diligence (CDD)/simplified due diligence (SDD) measures to the beneficiary to the standard set out in the Money Laundering and Terrorist Financing (Information on the Payer) Regulations 2017 and validate their identity based on a reliable independent source.
3. Where a PISP has a “reseller” type arrangement, in order to attest “yes”, the PISP must ensure that its “reseller” has contracts in place with its clients/beneficiaries and undertake customer due diligence to the same level.
4. Validation of beneficiary – The PISP must undertake an effective validation of the beneficiary account information (Account title, sort code and account number), either via CoP, AIS-based validation or reliable bank statement evidence.
5. And, finally, in all the instances when the PISP attests that there is a contract, they must obtain information and assess the purpose and nature of business of all the beneficiaries in the chain and the intended transactions.

Usage:

When the PISP can attest that they have a contractual relationship and have completed CDD/SDD and validated the beneficiary and its details, the PISP must attest CPI with ‘yes’.

For e.g. In scenarios where the customer is paying into their own accounts i.e. “TransfertoSelf”, the PISP would still have a contract with the payer PSU who is the ultimate beneficiary of funds and hence CPI risk indicator must be ‘yes’

Examples:

Accountancy firm allowing customers to pay for invoices using PISP–provided open banking service. 

Beneficiary Pre-Populated

Definition:

Beneficiary pre-populated is an OBL Proprietary risk indicator that is introduced to give additional assurance to the ASPSP that the PISP has completed due diligence with its clients as required under its contractual obligation. This is a binary yes / no indicator. The following conditions are required to be met before the PISP can attest ‘yes’ to this risk indicator otherwise the PISP must attest with a ‘no’.

Usage:

Validation of first beneficiary account details and pre-population – As referred to in section 5 above, PISP must complete validation of the beneficiary and their account details (beneficiary account name, sort code, account number or full IBAN). Once validation is complete, the beneficiary details i.e. the payee details, must be pre-populated by the PISP or the party who is a customer-facing entity when the payment is being initiated. These details are immutable and must not be altered by any parties involved in the chain including the PSU.

Examples:

Marketplace checkout purchases by PSU.

Beneficiary Account Type

Definition:

Beneficiary Account Type is an OBL Proprietary risk indicator that is introduced to give additional assurance to the ASPSP of the type of account the beneficiary is holding. The list is not aligned to the ISO 20022 account type and will be updated in the future.

This field provides details of the type of beneficiary account, one of the following 15 account types.

Usage:

The beneficiary account type must be of the first beneficiary account to which the payment is made even though there may be an ultimate beneficiary who has a different account.

However, the PISP must attest to the beneficiary account type only when they have fully verified or else the indicator must not be provided.

Note: If the PISP does not know the beneficiary then it is expected to not provide the risk indicator instead of providing it with a blank value. Since this is an optional indicator, the ASPSP must consider not providing the risk indicator by the PISP as ‘Unknown’.

Example:

Card Payments are made to a Collection account (first beneficiary) before posting to the cardholder’s account (ultimate beneficiary). Beneficiary account type = “Collection”.

Delivery Address

Definition:

Delivery address is the physical address where goods and services are required to be delivered This is based on ISO 20022 postal address type.

Usage:

The delivery address should be provided, as required. The PISP must ensure that the address is provided by the PSU and immutable by any parties in the chain. The ASPSP may have a mechanism to verify the address of the PSU if granular details of address type etc are provided.

Example:

Customers buying goods from the marketplace would require the goods to be delivered to their residential address.

Merchant Category Code (MCC)

Definition:

Merchant category codes (MCCs) are four-digit numbers used to classify businesses by the type of goods or services they provide. MCCs and their definitions are set by the ISO 18245:2023.  MCCs are assigned to merchants by credit card companies when they start accepting card payments. The MCC reflects the merchant’s primary business activity. MCCs are used by payment brands, issuers, and acquirers to categorize, track, and restrict transactions.

Usage:

PISPs should be able to provide MCCs when they have a contract with their client (CPI is ‘yes’) and they have an associated MCC. ASPSPs could use the MCCs for risk scoring if provided.

Example:

Customers buying goods from an ecommerce site. PISP provides the seller’s MCC.

Information flow Payment Status – SO Previous

Common Terminology – Preferred Terms and Language Next