[Openid-specs-fapi] VRP. Re: Strong MERCHANT Authentication
joseph at authlete.com
Mon Apr 13 19:23:06 UTC 2020
> On 13 Apr 2020, at 19:18, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> On 2020-04-13 18:08, Joseph Heenan wrote:
>>> On 13 Apr 2020, at 15:47, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>> On 2020-04-13 15:52, Joseph Heenan wrote:
>>>>> On 12 Apr 2020, at 07:21, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>>>>> How is FAPI going to handle VRP?
>>>> That’s essentially out of scope - but the alternate question of “How do you do VRP with FAPI” the answer is that you obtain authorization from the user for VRP (exactly the same as you would for a single payment, other than showing a differing consent request to the user), resulting in an access token (and optional refresh token) that allows long term access to a payment API that could be used to transfer money from a particular set of bank accounts.
>>>> VRP in the UK OpenBanking ecosystem has to solve two problems:
>>>> 1) the non-technical issue that the banks don’t want to do it (except potentially under a commercial contract)
>>> That's strange, similar schemes are in heavy use since ages back, albeit using other "APIs”.
>> All the similar schemes (at least in the UK) I’m aware of similarly require a commercial contract of one form or another - ApplePay & competitors, VISA/mastercard credit or debit, direct debits, etc.
> I was probably a bit too quick...the schemes you mention run under specific rule-books. In theory VRP could run under the same rule-book as direct payments which would be like:
> - if a payment doesn't get through due to lack of funds, the Merchant would NOT be guaranteed to get payed
> - Consumers would NOT be "automatically compensated" for incorrect payment requests
> An awful idea? well, I don't think that this *in practice* would introduce new issues since deviations anyway require measures by the affected party often including debt collection. It happens all the time with housing, electricity, and phone bills.
> For the banks everything is "cool" :-)
It’s not an awful idea, but it doesn’t change the problem: the banks don’t want to do it for free and (leaving aside the CMA9) nothing compels them to do it for free. The liability model you propose is also quite different to the one imposed for one-off PSD2 payments, which risks consumer confusion.
More information about the Openid-specs-fapi