11 February 2013

EPC: 'Quick Response Code - Guidelines to Enable Data Capture for the Initiation of a SEPA Credit Transfer'

This document sets out general guidelines for the use of a SEPA-wide quick response code to enable the data capture for the initiation of an SCT. It describes how the data capture prior to the initiation of an SCT can be made by means of a two-dimensional barcode.

A two-dimensional code consists of black modules arranged in a square pattern on a white background. A Quick Response (QR) code is an example of a 2D code (please see example provided on page 2).

The purpose of this document is to deal with 2D codes as a means of data capture enabling payment initiation whereby the code contains the required data for the originator to initiate a SEPA Credit Transfer (SCT). As a future step it proposes the inclusion of an optional security field that would certify the correspondence of the beneficiary name to the beneficiary account number.

The process starts with the payee printing the 2D code, for example, on the invoice to be sent. Upon receipt of the invoice, the payer scans the 2D code with a Smartphone, PC or scanner (either at home or at bank branch office) and by doing so the payer is directed to his online banking application where the payment details are pre-filled automatically. The payer then simply validates the transaction in order to complete the payment process.

This document is of an informative nature only and describes how the data capture prior to the initiation of an SCT can be made by means of a 2D code. Therefore, it is optional for PSPs adhering to the SCT scheme to implement this feature and offer it to their customers. Corporates or service providers that are interested in making use of 2D codes for payment processing should contact their PSP for additional information.

In addition to the described features, an electronic signature should – in a further step – be defined as an option to secure the integrity of the data elements contained in the two-dimensional code. Such a signature, when present, would ensure the secure correspondence between the beneficiary name and the beneficiary account number (in other words would protect the debtor against risk of one or more data element modifications, like IBAN substitution).

However, a single specification for such an electronic signature would be needed to ensure interoperability, and should be developed in a broader stakeholder forum involving for example European Standardisation Bodies, such as ETSI.

Press release

Full publication

 

© EPC