[Openid-specs-fapi] Withdrawal and Deposit use-case schema

Nat Sakimura nat at sakimura.org
Wed Dec 12 13:56:25 UTC 2018


Thanks Freddi,

Comments/further questions inline:


On 2018-12-12 19:56, Freddi Gyara wrote:
> Nat,
> 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)

In the mainstream scenario, there is no money-holding involved.
In a sub-scenario, there is a case where money-holding happens, but that
will be done by a licensed ASPSP/e-Money license holder.

> 
> 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.

That's very kind of you. We will keep sharing our idea.
Your and UK OB's comments are always welcome on our side as well.

> 
> 3. We do not have the 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.

Could you give me the pointer to the documentation about it?
My team apparently did not find it, so...

> 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.

That's great.

> 
> 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.

That's very kind of you. Your experience will definitely help us.

Best,

Nat Sakimura
> 
> Regards,
>  Freddi
> 
> -------- Original Message --------
>  From: Nat Sakimura via Openid-specs-fapi
> <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>,Ralph
> Bragg <Ralph.Bragg at openbanking.org.uk>
>  CC: Nat Sakimura <nat at sakimura.org>
>  Subject: [Openid-specs-fapi] Withdrawal and Deposit use-case schema
> Hi
> 
>  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:
> 
>  Withdrawal
>  -----------------
>  * DebtorAccount <-- The account of the PSU
>  * CreditorAccount <-- The account of the PISP (e.g., an ATM network)
> 
>  Deposit
>  -----------------
>  * 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.
> 
>  Best,
> 
>  --
>  Nat Sakimura
>  Research Fellow, Nomura Research Institute
>  Chairman of the Board, OpenID Foundation
>  _______________________________________________
>  Openid-specs-fapi mailing list
>  Openid-specs-fapi at lists.openid.net
>  http://lists.openid.net/mailman/listinfo/openid-specs-fapi [1]
> 
>  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.
> 
>  This email and any attachments are confidential and are intended for
> the above named only. They may also be legally privileged or covered
> by other legal rights and rules. Unauthorised dissemination or copying
> of this email and any attachments, and any use or disclosure of them,
> is strictly prohibited and may be illegal. If you have received them
> in error, please delete them and all copies from your system and
> notify the sender immediately by return email. You can also view our
> privacy policy (https://www.openbanking.org.uk/privacy-policy).
> 
> 
> Links:
> ------
> [1] http://lists.openid.net/mailman/listinfo/openid-specs-fapi


More information about the Openid-specs-fapi mailing list