This is the third blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Payment Fraud, or “APPF”.
It doesn’t, not least because it fails to set out, as a baseline, what the customer’s rights are in law now under the 2017 Payment Services Regulations (the “PSRs”), and fails to take a position on whether these PSRs cause a closer alignment of the term
“unique identifier” to the International Bank Account Number, and cannot be construed as a combination of the UK Sort Code and a customer’s Account Number.
The root cause of “wrong name” APPF is in the firms’ own IT infrastructure and in their payment schemes, and its primary result is that the firms pay the wrong beneficiary.
The beneficiary, at the behest of the payer’s firm, is identified by the payer in a payment order through the combination of a name and two pieces of numeric data. This ought to mean that the firms are not protected by Article 91 of the PSRs as the payment
has not been initiated using a “unique identifier”.
However, there has been a court case, albeit pre-dating the current PSRs, in which the court found that the combination of the Sort Code and Account Number represented a “unique identifier”. This seems to us to be a bizarre interpretation, and not just because
the Sort Code and the Account Number are each identifiers individually.
The EU Directive upon which the 2017 PSRs are based – Payment Services Directive 2 or 2366 of 2015 - defines “unique identifier” as definition 33: “a combination of letters, numbers or symbols specified to the payment service user by the payment service
provider and to be provided by the payment service user to identify unambiguously another payment service user and/or the payment account of that other payment service user for a payment transaction”. As it is “a” combination in the singular and not the plural,
the intention of the Directive was clearly that a “unique identifier” was a single piece of data, and not two pieces, albeit that it can be alphanumeric and contain symbols.
Article 45.1 of 2366/2015 determines that:
“Member States shall ensure that the following information and conditions are provided or made available by the payment service provider to the payment service user:
(a) a specification of the information or unique identifier to be provided by the payment service user in order for a payment order to be properly initiated or executed”.
The important point is that it is a unique identifier OR “the information”.
Under EU law a payment in Euro between two accounts in the UK must be capable of being completed with a “unique identifier”, and this is the International Bank Account Number or “IBAN”, a single string of alphanumeric characters. Importantly it is without
the BIC (“Business Identifier Code”) needing to be quoted as well. The firms’ trade body for payment schemes (Pay.uk) maintains an IBAN-only facility to enable this:
The facility derives the BIC from the IBAN, so as to enable firms’ processing, the BIC being the equivalent of the UK Sort Code. The need for the facility infers that UK firms cannot manage with IBAN alone, but need the BIC as well. This does not alter the
status of the IBAN as “unique identifier” in law but this “unique identifier” is inadequate to the needs of firms’ IT infrastructures: it does not then follow that the BIC can be understood as part of the “unique identifier”. UK firms have accepted this principle
regarding Euro payments – domestic in the UK and cross-border within the so-called SEPA Area – due to applicable EU and UK law but deny it regarding domestic payments in GBP.
It is valuable to note that the EU’s evolution to IBAN-only began with EU Regulation 2560 of 2001 regarding pricing of cross-border Euro credit transfers of up to EUR12,500 from July 2003 until July 2006, and up to EUR50,000 thereafter. The parity between
cross-border Euro credit transfers was contingent on the supply by the payer of IBAN+BIC, which are described in Article 5.2 of 2560/2001 as “the above information”.
The intention of the EU laws behind IBAN-only should be tested in the UK, as they form as much a part of the law as the articles within any EU Regulation or Directive. This test would nail down whether it is the intention of EU law that “unique identifier”
be synonymous with IBAN. The case would be made with reference to other EU instruments, beyond the Payment Services Directive 2 of 2015, and which reference IBAN and have promoted its usage without BIC in the period between 2009 and 2017, such as the SEPA
Migration End Date Regulation 260 of 2012 and the Funds Transfer Regulation 847 of 2015.
IBAN was scarcely in use even in the Eurozone in 2009, but the SEPA Migration End Date Regulation has caused it to be used for all domestic “push payments”, as well as direct debits, in Euro as well as for Euro cross-border “push payments” and direct debits
within the SEPA Area (which is the EEA plus certain extension territories).
If it can be proven that now IBAN is synonymous with “unique identifier”, it follows that the payment data that UK firms demand for domestic payments in GBP is not a “unique identifier” but “the information…that has to be provided by the payment service
user in order for a payment order to be properly initiated or executed” pursuant to Article 43.2.a of the 2017 PSRs.
It then follows that, for domestic payments, a UK firm contracts with the payer to make the payment on the basis of all this “information”, not part of it.
The firms have themselves specified this information as the mandatory fields – along with amount and date - in the eBanking services through which they accept the payment order. It is important to note that the information is mandatory: the eBanking service
will not accept the payment order unless all of the name, Sort Code and Account Number are present. Having asked for this mandatory information, the firms should be bound by a contract made pursuant to the PSRs to make the payment in accordance with it.