<div dir="ltr">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.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 5:49 AM Nat Sakimura via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Freddi,<br>
<br>
Comments/further questions inline:<br>
<br>
<br>
On 2018-12-12 19:56, Freddi Gyara wrote:<br>
> Nat,<br>
> 1 & 2. We haven't considered ATM based used-cases for open banking. I<br>
> suspect you should be able to proceed along the route that you have<br>
> outlined below. Do note that PSD2 has an explicit requirement that the<br>
> PISP should not "hold funds" at any point. This may not be relevant in<br>
> a non-EU jurisdiction and in EU jurisdictions PISPs may be able to do<br>
> so with additional licenses (e.g. PISPs that are ASPSPs or have an<br>
> e-Money license)<br>
<br>
In the mainstream scenario, there is no money-holding involved.<br>
In a sub-scenario, there is a case where money-holding happens, but that<br>
will be done by a licensed ASPSP/e-Money license holder.<br>
<br>
> <br>
> Would be happy to engage to help you'll map this out to your specific<br>
> situation and then use the exercise to influence our Version 4<br>
> specifications.<br>
<br>
That's very kind of you. We will keep sharing our idea.<br>
Your and UK OB's comments are always welcome on our side as well.<br>
<br>
> <br>
> 3. We do not have the means to affect a "single debit multi credit"<br>
> transaction along the lines that you described. In the Version 3 APIs,<br>
> we do return a list of Charges that will be levied in addition to the<br>
> payment by the ASPSP.<br>
<br>
Could you give me the pointer to the documentation about it?<br>
My team apparently did not find it, so...<br>
<br>
> The actual charge would have to be levied<br>
> through a separate transaction. I will request our policy team to have<br>
> a look at this use-case and whether there is demand in the market to<br>
> address this.<br>
<br>
That's great.<br>
<br>
> <br>
> The APIs are designed to work with both immediate and batch settlement<br>
> payment rails (e.g. FPS and BACS in the UK). We also have mapped the<br>
> APIs to the message payloads for SEPA and SEPA Instant as well. It<br>
> would be interesting to undertake a similar exercise for the rails<br>
> used in Japan. Again - let us know if this is something we could<br>
> assist with.<br>
<br>
That's very kind of you. Your experience will definitely help us.<br>
<br>
Best,<br>
<br>
Nat Sakimura<br>
> <br>
> Regards,<br>
>  Freddi<br>
> <br>
> -------- Original Message --------<br>
>  From: Nat Sakimura via Openid-specs-fapi<br>
> <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
>  Date: Wed, 12 Dec 2018, 02:11<br>
>  To: Openid-specs Fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>,Ralph<br>
> Bragg <<a href="mailto:Ralph.Bragg@openbanking.org.uk" target="_blank">Ralph.Bragg@openbanking.org.uk</a>><br>
>  CC: Nat Sakimura <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>><br>
>  Subject: [Openid-specs-fapi] Withdrawal and Deposit use-case schema<br>
> Hi<br>
> <br>
>  I have a question from my ATM team regarding the withdrawal and the<br>
>  deposit use-case schema. It deals with ATMs and prepaid cards as<br>
> PISPs.<br>
> <br>
>  They are considering APIs for these use-cases and considering using<br>
> the<br>
>  UK Open Banking's Payment API as follows:<br>
> <br>
>  Withdrawal<br>
>  -----------------<br>
>  * DebtorAccount <-- The account of the PSU<br>
>  * CreditorAccount <-- The account of the PISP (e.g., an ATM network)<br>
> <br>
>  Deposit<br>
>  -----------------<br>
>  * DebtorAccount <-- The account of the PISP (e.g., an ATM network)<br>
>  * CreditorAccount <-- The account of the PSU<br>
> <br>
>  Note: They are looking at the version 1.1.0.<br>
> <br>
>  Q.1 Is the above within the target scope of the Open Banking?<br>
> <br>
>  Q.2 If not, do you have plans to create the API specs that take care<br>
> of<br>
>  the withdrawal and the deposit use-case?<br>
> <br>
>  Q.3 When some of the participating parties take fee during the<br>
> Payment,<br>
>  how is it dealt in the API context? Are there going to be a separate<br>
>  Payment for the fee associated with the main transaction?<br>
> <br>
>  During the FAPI call (Pacific) today, we talked about it in the US<br>
>  context and I found that the situation is very different than in<br>
> Japan.<br>
>  In Japan, we have started the instant payment back in 1973 so that is<br>
> <br>
>  the norm here, which means that there is no "taking the risk of the<br>
>  transaction not clearing" while it seemed it is the case in the US.<br>
>  Naturally, the API model then will be different. I was wondering what<br>
> <br>
>  would be the situation in the context of the UK Open Banking.<br>
> <br>
>  Best,<br>
> <br>
>  --<br>
>  Nat Sakimura<br>
>  Research Fellow, Nomura Research Institute<br>
>  Chairman of the Board, OpenID Foundation<br>
>  _______________________________________________<br>
>  Openid-specs-fapi mailing list<br>
>  <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
>  <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a> [1]<br>
> <br>
>  Please consider the environment before printing this email.<br>
> <br>
>  This email is from Open Banking Limited, Company Number 10440081. Our<br>
> registered and postal address is 2 Thomas More Square, London, E1W<br>
> 1YN. Any views or opinions are solely those of the author and do not<br>
> necessarily represent those of Open Banking Limited.<br>
> <br>
>  This email and any attachments are confidential and are intended for<br>
> the above named only. They may also be legally privileged or covered<br>
> by other legal rights and rules. Unauthorised dissemination or copying<br>
> of this email and any attachments, and any use or disclosure of them,<br>
> is strictly prohibited and may be illegal. If you have received them<br>
> in error, please delete them and all copies from your system and<br>
> notify the sender immediately by return email. You can also view our<br>
> privacy policy (<a href="https://www.openbanking.org.uk/privacy-policy" rel="noreferrer" target="_blank">https://www.openbanking.org.uk/privacy-policy</a>).<br>
> <br>
> <br>
> Links:<br>
> ------<br>
> [1] <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div>