<div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Hi Anders, Tom,</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">So Anders you are right that the current FAPI profile supports "redirect" based auth flows.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">This can work for e-commerce applications, but as you say is not ideal for payments made at a POS terminal.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">To support this latter type of payment we are developing a FAPI profile for CIBA - client initiated backchannel authentication: <a href="https://bitbucket.org/openid/fapi/src/30b573f771ac1ebbee00aacc159f82da3c36e09b/Financial_API_WD_CIBA.md?at=master&fileviewer=file-view-default">https://bitbucket.org/openid/fapi/src/30b573f771ac1ebbee00aacc159f82da3c36e09b/Financial_API_WD_CIBA.md?at=master&fileviewer=file-view-default</a></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">This approach brings in the concept of a "consumption device" and an "authentication device". The consumption device may be a POS terminal and the authentication device could be a user's smartphone. The nice thing about using CIBA is that many of the APIs defined in OpenBanking should "just work" - CIBA simply defines a different flow for gaining an access token.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">The basic flow would be as follows:</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">1. User presents some identifier at POS terminal (this could be via a card, or phone number, etc.)</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">2. The user identifier is submitted to a third party (in PSD2 terms, a payment initiation service provider - PISP)</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">3. The PISP is already registered as an OAuth client with various banks</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">4. The PISP sends the user identifier along with data about the proposed payment to the bank </div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">5. The bank verifies the PISP is a valid client, and then sends a push notification to the customer's phone</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">6. The customer is taking through the process of authentication, and authorization of the payment</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">7. Once the customer has authorised the payment, an access token is sent to the PISP</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">8. The PISP uses this access token to execute the payment</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Tom, I understand some of your concerns, however, I believe that the move towards open APIs in banking, will enhance the security of payments and give end-users more visibility and control over their accounts. There is currently a need for strong legislative protection around consumer payments because they are so insecure and at risk of fraud. The various FAPI profiles should provide a way for all 3 parties - the bank, the payment initiation service provider, and the end-user to have confidence and assurance about any particular transaction. </div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Dave</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 November 2017 at 19:44, Tom Jones via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">that is far more of a legal/liability problem than a technical one.<div>In the us there are 3 mechanisms, all with separate legal/liability results.</div><div>Credit cards are not banking in the sense you mean, but are controlled by the FED, reg CC. Consumer liability limited to $50 which is usually not worth the time to collect.</div><div>Debit cards apply directly to the user's bank account and so are very dangerous. I encourage people to avoid them like the plague.</div><div>ACH payments are bank account to bank account and are more like traditional banking drafts.</div><div>Because of the weak protection around ACH payments the release of the consumers bank routing number is very risky.</div><div>I believe that the introduction of a write api that can extract $ from a consumer's  bank account will result in massive losses that will result in long legal tussles to determine who pays the bill.</div><div>I can see no good coming from such a write api against consumer or small business bank balances.   ..tom</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="m_1250944675089986007gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Mon, Nov 13, 2017 at 11:20 AM, Anders Rundgren <span dir="ltr"><<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a><wbr>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2017-11-13 19:20, Tom Jones wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I thought i was directly addressing that point. I guess the problem, as usual, is one of semantics.<br>
</blockquote>
<br></span>
Yes, I was addressing this from a purely technical level where<br>
transferring money from an account to another entity using an<br>
on-link bank application is currently performed through [technically]<br>
entirely different means compared to using a payment card connected<br>
to the same account.<br>
<br>
The hope is [apparently] that open banking APIs will finally unify<br>
the technical side of money transfers, right?<br>
<br>
Cheers,<br>
Anders<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
Banking originally applied to depository financial institutions (DFI) only.<br>
The banks were fiduciary holders of funds on the behalf of depositors.<br>
That is the basis for the financial regulations of the first 1/3 of the 20th century.<br>
Customers issued bank drafts (checks) against their funds, those were payments to the holder of the draft.<br>
Bank cards allows account holders access to their funds 24x7 at ATMs.<br>
<br>
Consumer payments originally applied to credit card accounts which were approved drafts signed by the holder of the account.<br>
This started to change with the initiation of MOTO - mail order telephone order - payments.<br>
But the big change occurred when banks learned that they could make more money from fees than from deposits.<br>
<br>
Today i guess i would say that "banking" is anything that the account holder initiates on his own behalf.<br>
Payments are anything that an FI does against a user account that does not have an immediate consumer draft as back up.<br>
<br>
Clearly the banks want to move us to a brave new world where they do things to our account and declaim any responsibility if anything goes wrong.<br>
Check some of Ross Anderson's articles if you disagree with that statement.<br>
It seems to date that all apis approved by the banks are in furtherance of such an movement.<br>
In particular that means that if an aggregator can "write" to the bank, it is no long in the realm of "banking".<br>
<br>
Peace ..tom<br>
<br></span><span>
On Sun, Nov 12, 2017 at 10:27 PM, Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gm<wbr>ail.com</a>>> wrote:<br>
<br>
    On 2017-11-12 04:14, Tom Jones wrote:<br>
<br>
        i am not sure about the eu, but in the us the ach payment method is not constrained by any dollar limit.<br>
        ANSI X9.59 addressed limits and user consent. AFAICT there is no protection for users in UK open banking or FAPI.<br>
        It's all banks all the way down.<br>
        Now if we could find a way to make it a claim, then OpenID can handle it.<br>
<br>
<br>
    I'm not sure that this is really what I'm asking for, it is rather a comment/reaction to my somewhat heretic claim that "Banking" and "Consumer Payments" are quite different and probably do not gain by being dealt by a generic payment initiation API and associated security model.<br>
<br>
    A "visual" of that could be taking a peek at these URL's<br></span>
    <a href="https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant" rel="noreferrer" target="_blank">https://www.openbanking.org.uk<wbr>/read-write-apis/payment-initi<wbr>ation-api/v1-1-0/#usage-exampl<wbr>es-merchant</a> <<a href="https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant" rel="noreferrer" target="_blank">https://www.openbanking.org.u<wbr>k/read-write-apis/payment-init<wbr>iation-api/v1-1-0/#usage-examp<wbr>les-merchant</a>><br>
    <a href="https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf" rel="noreferrer" target="_blank">https://cyberphone.github.io/d<wbr>oc/saturn/saturn-authorization<wbr>.pdf</a> <<a href="https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf" rel="noreferrer" target="_blank">https://cyberphone.github.io/<wbr>doc/saturn/saturn-authorizatio<wbr>n.pdf</a>><span><br>
    which address the same use case.<br>
<br>
    As far as I can tell there is no wallet concept in the FAPI, STET or OpenBanking schemes, whereas the Saturn architecture does away with the PISP altogether since it doesn't depend on direct account access (Banking <<>> Consumer Payments).<br>
<br>
        Peace ..tom<br>
<br>
<br>
    Cheers,<br>
    Anders<br>
<br>
<br></span><span>
        On Fri, Nov 10, 2017 at 10:28 PM, Anders Rundgren via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openi<wbr>d.net</a> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@list<wbr>s.openid.net</a>> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@list<wbr>s.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@list<wbr>s.openid.net</a>>>> wrote:<br>
<br>
             Dear payment aficionados,<br>
<br>
              From what I can deduct, FAPI currently supports a single payment method ("transfer"):<br></span>
        <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default" rel="noreferrer" target="_blank">https://bitbucket.org/openid/f<wbr>api/src/master/Financial_API_W<wbr>D_005.md?fileviewer=file-view-<wbr>default</a> <<a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default" rel="noreferrer" target="_blank">https://bitbucket.org/openid/<wbr>fapi/src/master/Financial_API_<wbr>WD_005.md?fileviewer=file-view<wbr>-default</a>> <<a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default" rel="noreferrer" target="_blank">https://bitbucket.org/openid/<wbr>fapi/src/master/Financial_API_<wbr>WD_005.md?fileviewer=file-view<wbr>-default</a> <<a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default" rel="noreferrer" target="_blank">https://bitbucket.org/openid/<wbr>fapi/src/master/Financial_API_<wbr>WD_005.md?fileviewer=file-view<wbr>-default</a>>><br>
<br>
             After going a bit deeper into the matter including a brief study of the STET PSD2 API (<a href="https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html" rel="noreferrer" target="_blank">https://www.stet.eu/en/news/n<wbr>ews1/stet-psd2-api-is-now-avai<wbr>lable.html</a> <<a href="https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html" rel="noreferrer" target="_blank">https://www.stet.eu/en/news/n<wbr>ews1/stet-psd2-api-is-now-avai<wbr>lable.html</a>> <<a href="https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html" rel="noreferrer" target="_blank">https://www.stet.eu/en/news/n<wbr>ews1/stet-psd2-api-is-now-avai<wbr>lable.html</a> <<a href="https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html" rel="noreferrer" target="_blank">https://www.stet.eu/en/news/n<wbr>ews1/stet-psd2-api-is-now-avai<wbr>lable.html</a>>>), it seems that FAPI and its "cousins" indeed properly address payments when performed in the context of "Banking", but somewhat less so for "ordinary" payment operations like performed at a POS terminal or automated gas station.<span><br>
<br>
             Comments?<br>
<br>
             Thanx,<br>
             Anders Rundgren<br>
             ______________________________<wbr>_________________<br>
             Openid-specs-fapi mailing list<br></span>
        <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid<wbr>.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@list<wbr>s.openid.net</a>> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@list<wbr>s.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@list<wbr>s.openid.net</a>>><br>
        <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-fapi</a> <<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailm<wbr>an/listinfo/openid-specs-fapi</a>> <<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailm<wbr>an/listinfo/openid-specs-fapi</a> <<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailm<wbr>an/listinfo/openid-specs-fapi</a>><wbr>><br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:'Open Sans';font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165);text-decoration:none" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border:none;padding:0px;border-radius:2px;margin:7px"></a></div><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px;background-color:transparent">10 Temple Back, Bristol, BS1 6FL</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br></div><div style="color:rgb(97,97,97);font-size:14px;font-weight:normal;font-family:lato,"open sans",arial,sans-serif"><font color="#00a4b7"><span style="font-size:11px;line-height:15.925px"><br></span></font><div style="color:rgb(51,51,51);line-height:1.4"><span style="font-size:0.75em">Moneyhub Enterprise is a trading style of Momentum Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Momentum Financial Technology is entered on the Financial Services Register </span><span style="font-size:0.75em;background-color:transparent">(FRN </span><span style="font-size:0.75em;background-color:transparent;color:rgb(0,164,183);font-weight:bold">561538</span><span style="font-size:0.75em;background-color:transparent">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. Momentum Financial Technology is registered in England & Wales, company registration number </span><span style="font-size:0.75em;color:rgb(0,164,183);font-weight:bold;background-color:transparent">06909772</span><span style="font-size:0.75em;background-color:transparent"> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:transparent"><font size="1">©</font></span><span style="font-size:0.75em;background-color:transparent"> . </span><span style="background-color:transparent;font-size:0.75em">Momentum Financial Technology Limited 2016. </span><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Momentum Financial Technology Limited or of any other group company.</span></div></div></div></div></div></div></div></div></div></div></div>
</div>