Transaction Risk Indicators (TRIs) for cVRP

Applies from: 29 January 2027 Applies to: PISPs

From 29 January 2027, PISPs must accurately complete a set of Transaction Risk Indicator (TRI) fields on all commercial Variable Recurring Payment (cVRP) consents and transactions. TRIs give ASPSPs context on the nature of a payment, the relationship between the parties involved, and the conditions under which it was initiated — enabling more targeted fraud interventions.

This page sets out each TRI, when it applies, how to determine the correct value, and the corresponding field in the Token.io API reference.

All TRI fields are submitted as part of the risk object, present on both the VRP consent (vrpConsent.initiation.risk) and the payment initiation (paymentInitiation.risk) payloads.

Contract Present Indicator (CPI): this TRI is not covered on this page. Given the Money Laundering Regulations due diligence Token.io already performs on merchants during onboarding, Token.io defaults contractPresentIndicator to true on all cVRP consents and payments. No action is required from clients for this field.

Summary

Before you start: how Token.io splits TRI responsibility

Not every TRI needs to be supplied by your integration on every transaction. Some describe fixed attributes of a merchant relationship and are set up once by Token.io at onboarding; others describe the specific transaction and must be supplied by your integration each time.

For BPI, BAT and MCC, Token.io sets a default value at onboarding. If your integration supplies a value for one of these fields on the consent or payment request, that value takes priority over the onboarding default. PPC, PCC and Delivery Address are never defaulted by Token.io — your integration must supply a value on every request, since these are transaction-specific by nature.

• Accuracy is the PISP's responsibility. This holds even where a transaction is completed by an agent or merchant acting on the PISP's behalf, and even where Token.io has set a default for BPI, BAT or MCC — if a merchant's circumstances change (new settlement account, newly assigned MCC, integration change), let Token.io know so the onboarding defaults stay accurate.
• Consent values and transaction values can differ. It's expected and permitted for the TRIs provided at consent to differ from those provided on an individual subsequent transaction. Note that ASPSPs may apply a risk-based approach to fraud checks where this happens, so it's worth ensuring values are as accurate as possible at both stages.

Defaulted at onboarding (your request value takes priority)

1. Beneficiary Prepopulated Indicator (BPI)

Token.io API field: risk.beneficiaryPrepopulatedIndicator Type: Boolean (True / False)

Reflects whether the PISP (or Token.io, on its behalf) pre-populates the payee's account details for the PSU, and whether those details are immutable during the transaction journey. This is a property of how the integration is built, not of any individual transaction — so Token.io sets a default for this field at onboarding. If your integration supplies beneficiaryPrepopulatedIndicator on a request, that value takes priority over the onboarding default.

To attest True, both of the following must be met (if either is not met, the flag must be False):

1. The PISP (or its agent, on its behalf) pre-populates the Payee Account Name and Payee Account Identification details (sort code and account number, or full IBAN) for the PSU.
2. These pre-populated fields are immutable — they cannot be altered by the PSU during the transaction journey.

All cVRP transactions are expected to be able to assert True for this indicator.

2. Beneficiary Account Type (BAT)

Token.io API field: risk.beneficiaryAccountType

PISPs must attest the type of the destination account in the cVRP mandate. A merchant's settlement account type doesn't change between transactions, so Token.io sets a default for this field at onboarding. If your integration supplies beneficiaryAccountType on a request, that value takes priority over the onboarding default. If funds move on beyond that destination account, the PISP should separately assess whether an Ultimate Creditor also needs to be declared.

While the Open Banking Standard defines 15 account types generally, only 5 are permitted for cVRP:

There is no "unknown" enumeration — a PISP is expected to know the beneficiary account type in every case.

Note: the API's beneficiaryAccountType enum includes additional values not permitted for cVRP (JOINT_PERSONAL, PERSONAL_SAVINGS_ACCOUNT, BUSINESS_SAVINGS_ACCOUNT, COLLECTION, CORPORATE, EWALLET, INVESTMENT, PREMIER, WEALTH, PENSION). These remain valid for other Open Banking use cases, but only the five values above should be used for cVRP.

3. Merchant Category Code (MCC)

Token.io API field: risk.merchantCategoryCode

Assigned once by an acquirer through card scheme participation — a static classification of the merchant rather than something that varies by transaction. Token.io sets a default for this field at onboarding where applicable. If your integration supplies merchantCategoryCode on a request, that value takes priority over the onboarding default.

Must be completed when the merchant already has an MCC assigned to them by an acquirer through participation in a card scheme.

• Not required where the merchant or beneficiary has never been part of the cards ecosystem and has never had an MCC assigned.

Always supplied per transaction (never defaulted)

4. Payment Purpose Code (PPC)

Token.io API field: risk.paymentPurposeCode

The PPC identifies why a payment is being made. The Open Banking Standard normally draws on the full ISO 20022 purpose code list, but for cVRP, PISPs must use a truncated list of 26 codes defined by UKPI.

Note: the API reference documents paymentPurposeCode as a free-text string field, with its example values drawn from the generic ISO 20022 purpose code list (e.g. CASH, CORT, DVPM). For cVRP, do not use that generic list — populate this field with the applicable code from the UKPI Wave 1 list below instead.

Token.io does not set a default for this field. Your integration must supply an accurate paymentPurposeCode on every consent and transaction, updated dynamically where a merchant's transactions span more than one purpose. If you hit an edge case that doesn't map cleanly to this list, flag it to UKPI so the guidance can be refined.

5. Payment Context Code (PCC)

Token.io API field: risk.paymentContextCode (enum: PaymentContextCode)

The PCC explains the relationship between the PISP, the PSU and the beneficiary, and the conditions that led to the transaction being initiated. There are four permitted values for Wave 1, which map to the following paymentContextCode enum values in the Token.io API:

Note: the API's PaymentContextCode enum also includes PISP_PAYEE and INVALID_PAYMENT_CONTEXT_CODE. Neither of these applies to the four Wave 1 categories below — do not use them for cVRP.

Token.io does not set a default for this field. Your integration must supply an accurate paymentContextCode on every consent and transaction, updated dynamically where a merchant's transactions span more than one context (e.g. some in-store, some online).

How to choose the right value

Work through these questions in order:

1. Is the payer and payee the same person or entity?
   • Yes → TransferToSelf
   • No → go to 2
2. Is the payment set up via a payment interface, checkout, or billing process controlled by the biller/merchant?
   • No → TransferToThirdParty
   • Yes → go to 3
3. Is the PSU physically present in the same location as the biller/merchant at the point of initiation?
   • Yes → Payment to Merchant/Biller – F2F
   • No → Payment to Merchant/Biller – Remote

Definitions

TransferToSelf The PISP attests that the transaction is a transfer of funds between accounts held in the name of, or for which liability rests with, the same PSU. This includes jointly held financial products, whether as the origin or destination account.

The critical test is that the destination account is in the same name or the same liability rests with the same PSU. If the PISP cannot attest to this, a different PCC must be used.

Examples: movement of own funds to another current account, a savings account, an investment account, a pension account, a loan, a credit card, a mortgage or other secured lending, or a wallet.

Payment to Merchant/Biller – Remote (Covers the enumerations EcommerceMerchantInitiatedPayment, BillingGoods&ServicesInAdvance, and BillingGoods&ServicesInArrears — all three map to this single definition for cVRP.)

A payment initiated by a PSU to a payee where the payment is set up via a payment interface, checkout or billing process presented or controlled by that payee, and the customer is not in the same physical location as the provider of the goods/services at the point of initiation.

There are two varieties:

• In Session — the consent and each individual transaction are set up by the PSU via the payee's payment interface.
• Off Session — the consent is set up by the PSU via the payee's payment interface, but ongoing transactions are initiated automatically without the PSU being present in that interface.

Applies where any of the following is true:

• The PISP has a contractual relationship with the merchant for the provision of open banking payment acceptance services.
• The PISP resells its services to other parties who contract with merchants.
• The PISP is the ultimate beneficiary itself.

Examples: e-commerce purchases, charity payments, government tax or fine payments, utility/telco/insurance payments — ad hoc or recurring.

Payment to Merchant/Biller – F2F (Covers the enumerations FaceToFace and PointOfSale.)

The PISP attests that the payment relates to an in-person payment from a consumer to a business or charity, where the customer is physically present in the store — even if using an app or web browser to make the payment.

The same three contractual scenarios apply as for the Remote category (contractual relationship with the merchant, reseller arrangement, or PISP as ultimate beneficiary).

The critical feature is that payment initiation occurs in a face-to-face environment — not the consent, which could have been set up remotely in advance. This could be via a QR code, payment link, or direction to an app or web browser, provided the PSU is physically in the same location as the merchant/biller when initiation occurs.

Examples: retail payments where the customer is physically present in-store or face-to-face with the merchant.

TransferToThirdParty Transfer of funds between accounts held by different people or legal entities. Expected to be extremely rare in cVRP.

Examples: P2P and P2B transactions where the PISP has no contractual arrangement with the payee — e.g. gifts to family and friends — and any transaction where the PISP cannot attest to the conditions of the other three categories.

6. Delivery Address

Token.io API field: risk.deliveryAddress (object)

By definition transaction-specific — varies by order or shipment, so Token.io does not set a default for this field. Must be completed accurately by your integration where known by the PISP and appropriate to the transaction.

• Required for the delivery of physical goods, where the PISP knows the address.
• Not required for services or non-physical goods, where a delivery address wouldn't be applicable.

All fields listed above must be completed accurately for every consent and transaction from 29 January 2027. Contract Present Indicator (CPI) is handled separately by Token.io — see the note at the top of this page.

If you have any feedback about the developer documentation, please contact devdocs@token.io