EPC: Public consultation on draft document “standardisation of QR-CODES for MSCTS”

On 16 February 2022, the European Payments Council (“EPC”) launched an eight-week public consultation on a new draft document – see here – on the Standardisation of Quick-Response (QR)-codes for mobile initiated (instant) credit transfers (MSCTs), aimed at standardising a payee and a payer-presented QR-code for all types of MSCTs (person-to-person, consumer-to-business, business-to-business and business-to-consumer, while addressing both Instant Credit Transfer and SCT payments).

This consultation is open for comments until 14 April 2022 and all interested stakeholders are invited to participate by sending their feedback using the dedicated questionnaire available here. We strongly recommend that companies using, or intending to use, MSCT instruments to review this document in detail, and consider submitting comments.

MSCTs in brief

MSCTs are initiated directly (by the payer) or indirectly (by an IP service provider at the request of the payer) in compliance with the PSD2, using a mobile device.

MSCT solutions are offered by so-called MSCT service providers which are service providers that offer or facilitate a payment service to a payer/payee based on an SCT Instant or an SCT transaction. As an example, an MSCT service provider could be a Payment Services Provider “PSP” (e.g. an Account Servicing Payment Service Providers (“ASPSP”) or any party acting as a Payment Initiation Service Provider (“PISP”) under Directive 2015/2366 - “PSD2”) or a technical service provider supporting a PSP.

MSCTs in Euro are based on the existing SCT Instant scheme or SCT Scheme rulebooks and in the so-called “inter-PSP space” and are therefore using the existing payment infrastructure in that space.

They typically use an MSCT application or a browser on the user device to initiate or at least authenticate and authorise the SCT (Instant) transaction, as well as some features of the payer device such as the support of CDUVM (a user verification method entered by or captured from the user on their device – e.g. a mobile code or biometrics on the mobile device), the mobile device screen and to display transaction information, etc.

In most cases of MSCTs, both payer and payee have different ASPSPs that are SCT Inst or SCT scheme participants, while the entities assuming the role of MSCT service provider are mostly separate entities that are different for the payer and the payee. Obviously, if the role of MSCT service provider would be assumed by an ASPSP the model would be simplified.

Alternatively, multiple PSPs (such as a PISP licensed under PSD2 or a Collecting Payment Service Provider that collects the payment transactions on behalf of the merchant) could be involved between the payer/payee and their respective ASPSP. These models have been studied in Chapter 20 in the “EPC269-19v2.0 (2nd release): Mobile Initiated SEPA (Instant) Credit Transfer Interoperability Guidance” (“MSCT IG”) – which is due to be published.

As depicted above, the payer’s MSCT service provider is linked to the payer’s ASPSP and the payee’s MSCT service provider may be linked to the payee’s ASPSP (this linkage may include both technical and contractual aspects).

The MSCT ecosystem involves some other new stakeholders in the value chain compared to the ones described in the SCT Inst or SCT scheme rulebooks including a so-called Token Service Provider (“TSP”) who is a TTP involved if tokens are used in MSCTs as surrogate values for the transaction data (including the merchant/consumer IBAN, merchant/consumer identifier, transaction amount or merchant transaction identifier). The TSP manages the generation and issuance of tokens and maintains the established mapping of tokens to the related transaction data.

Standardisation of QR-codes for MSCTs

The EPC’s document specifies a minimum data set and a QR-code standard for MSCTs, covering two modes:

1. payee-presented QR-codes;
2. payer-presented QR-codes;

to contribute to the interoperability of such means of payments.

The minimum data set to be exchanged between the payee and the payer, will rely on the MSCT transaction features depending on whether the data provided contains a token, a proxy or all transaction data “in clear” (e.g. in clear in QR-code).

In any case, for the development of a standardised QR-code for MSCTs, based on ISO/IEC 18004, the following four assumptions have been followed:

• mobile wallets will often support multiple payment methods. The wallet user will often select and set a default payment method;
• Payees (e.g. merchants) may often support multiple payment methods. The payee could set a preferred (prioritised) payment method for MSCTs based on payee-presented QR-code;
• Need to avoid any special actions (e.g. all extra actions generate friction, such as asking what kind of wallet or what kind of payment instrument the payer would like to use from merchant personnel at Point Of Interaction - i.e. the initial point in the merchant’s environment (e.g. POS, vending machine, payment page on merchant website, QR-code on a poster, etc.) where data is exchanged with a consumer device (e.g., mobile phone, wearable, etc.) or where consumer data is entered to initiate an instant credit transfer);
• Need to avoid any special actions from the wallet user at the POI (more in particular in stores - e.g. swiping through a POS-menu to find a specific wallet generates friction).

Chapter 5 of the EPC’s document also contains some security aspects related to the data contained in QR-codes used to initiate MSCTs.

It is worth noting that a QR-code may contain both sensitive and non-sensitive payment data that can be used by different entities involved in the processing of the MSCT transaction.

In principle, a QR-code code can be static, or dynamic to initiate/identify a single specific MSCT transaction. Tampering with QR-code data may lead to fraudulent transactions or data leakage. Therefore, the sensitive payment data in the QR-code should be adequately protected and, the integrity of the data elements in the QR-code should be also be protected to avoid any service disruptions. Non-sensitive data may be related to the application information such as, name, download URL, etc. - this type of data can remain visible, to be available for a plain QR-code scanner but also for marketing or user information purposes.

Note that it is proposed that the governance aspects related to the usage of QR-codes should become part of the overall Governance of an “Interoperability Framework for MSCTs”. The latter also involves the establishment of a so-called Registration Authority for the issuance of MSCT service provider identifiers.

If you would like to receive our regular Payments alerts in your inbox, click here.

If you would like to read Bird & Bird’s previous alerts, please check out our Payments In Focus webpage here.