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

[Tom Jones]

The situation in the US is actually pretty much the same as Freddi
outlined. The are immediate (cash-like) payments when (e.g.) using an ATM
card and batch reconciled (check-like) payments which are part of the
US-wide nightly reconciliation of inter-bank payments. So different payment
protocols will have different reconciliation rules depending on the path
they implement.
Peace ..tom


On Wed, Dec 12, 2018 at 5:49 AM Nat Sakimura via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> 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
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20181213/3a125ba4/attachment.html>