[Openid-specs-fapi] Withdrawal and Deposit use-case schema
Freddi.Gyara at openbanking.org.uk
Wed Dec 12 10:56:45 UTC 2018
1 & 2. We haven't considered ATM based used-cases for open banking. I suspect you should be able to proceed along the route that you have outlined below. Do note that PSD2 has an explicit requirement that the PISP should not "hold funds" at any point. This may not be relevant in a non-EU jurisdiction and in EU jurisdictions PISPs may be able to do so with additional licenses (e.g. PISPs that are ASPSPs or have an e-Money license)
Would be happy to engage to help you'll map this out to your specific situation and then use the exercise to influence our Version 4 specifications.
3. We do not have a means to affect a "single debit multi credit" transaction along the lines that you described. In the Version 3 APIs, we do return a list of Charges that will be levied in addition to the payment by the ASPSP. The actual charge would have to be levied through a separate transaction. I will request our policy team to have a look at this use-case and whether there is demand in the market to address this.
The APIs are designed to work with both immediate and batch settlement payment rails (e.g. FPS and BACS in the UK). We also have mapped the APIs to the message payloads for SEPA and SEPA Instant as well. It would be interesting to undertake a similar exercise for the rails used in Japan. Again - let us know if this is something we could assist with.
-------- Original Message --------
From: Nat Sakimura via Openid-specs-fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>>
Date: Wed, 12 Dec 2018, 02:11
To: Openid-specs Fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>>,Ralph Bragg <Ralph.Bragg at openbanking.org.uk<mailto:Ralph.Bragg at openbanking.org.uk>>
CC: Nat Sakimura <nat at sakimura.org<mailto:nat at sakimura.org>>
Subject: [Openid-specs-fapi] Withdrawal and Deposit use-case schema
I have a question from my ATM team regarding the withdrawal and the
deposit use-case schema. It deals with ATMs and prepaid cards as PISPs.
They are considering APIs for these use-cases and considering using the
UK Open Banking's Payment API as follows:
* DebtorAccount <-- The account of the PSU
* CreditorAccount <-- The account of the PISP (e.g., an ATM network)
* DebtorAccount <-- The account of the PISP (e.g., an ATM network)
* CreditorAccount <-- The account of the PSU
Note: They are looking at the version 1.1.0.
Q.1 Is the above within the target scope of the Open Banking?
Q.2 If not, do you have plans to create the API specs that take care of
the withdrawal and the deposit use-case?
Q.3 When some of the participating parties take fee during the Payment,
how is it dealt in the API context? Are there going to be a separate
Payment for the fee associated with the main transaction?
During the FAPI call (Pacific) today, we talked about it in the US
context and I found that the situation is very different than in Japan.
In Japan, we have started the instant payment back in 1973 so that is
the norm here, which means that there is no "taking the risk of the
transaction not clearing" while it seemed it is the case in the US.
Naturally, the API model then will be different. I was wondering what
would be the situation in the context of the UK Open Banking.
Research Fellow, Nomura Research Institute
Chairman of the Board, OpenID Foundation
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net
Please consider the environment before printing this email.
This email is from Open Banking Limited, Company Number 10440081. Our registered and postal address is 2 Thomas More Square, London, E1W 1YN. Any views or opinions are solely those of the author and do not necessarily represent those of Open Banking Limited.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi