End user needs

xxx

In our Strategy, we prioritised the collaborative development of requirements and rules for 3 EUN solutions. These are:

1. ‘Request to Pay’ which addresses detriments arising from a lack of sufficient control, flexibility and transparency in the current payment mechanisms to meet the evolving needs of some end-users. Apart from anything else, this is why there's no need for "pull" payments in NPA.
2. ‘Assurance Data’ which addresses the lack of adequate assurance to the payer that they have sufficient funds to make a payment; that they are making the payment to the intended payee’s account and status of the payment once they make the payment. Right now, the assurance services envisaged are confirmation of available funds, payment tracking and the slightly more complex confirmation of payee.
3. ‘Enhanced Data’ which addresses the limited capacity, in current payment systems, to carry more structured data alongside the payment.

The reason why I call the payee confirmation service more complex is… well… it’s more complex. As I said in connection with this last year:

There’s a long way to go with this though, because there are privacy and other issues. Is it any of my business what the name on your account is?

From Are the banks telling you that you may as well use bitcoin? | Consult Hyperion

The CoP will be a real-time 24/7 services and the response provided to the payer will be as clear and unequivocal as possible to allow the payer to make a decision that he or she is making the payment to the intended payee. All to the well and good. But you can see the problems lurking in the shadows of this apparently reasonable requirement. An obvious issue is that data protection regulations must be considered to ensure that payer data is handled lawfully especially in the case where the account information is played back. If you send a payment to your dentist, for example, should be provided with your dentist's real name, address and other personally-identifiable information (PII). I would have thought not. Then there's also the issue of accuracy and liability for incorrect information. And consider also that is some cases the system must not return the "correct" information (as part of law enforcement operationa, for example).

This isn’t just about bank accounts and instant payments, of course. If it was, I wouldn’t be blogging about it. I hate to say it, but the problem and the solution are all about identity.

From Super-complaints but no super-solutions | Consult Hyperion

One safeguard that the PSF puts forward is that the payee confirmation service can only be utilised for the purposes of making a payment and it assumes that PSPs will ensure relevant safeguards are put in place to ensure prudent use (e.g., to guard against phishing, profiling etc.). OK, so I may sound like a broken record on this, but without a working digital identity infrastructure in place, we will end up with something incomplete and expensive getting hacked up to support NPA implementation alone.

 

I wrote last year that

I imagine that an outcome of Payment UK’s deliberations on payee confirmation may well be the creation of a database of “paynames” (i.e., £dgwbirch) to make casual instant payments even easier.

From There you go bringing class into it again | Consult Hyperion

xxx