[Openid-specs-fapi] FAPI support for Bookings, Reservations, Etc. ?

Anders Rundgren anders.rundgren.net at gmail.com
Mon Nov 13 19:20:12 UTC 2017


On 2017-11-13 19:20, Tom Jones wrote:
> I thought i was directly addressing that point. I guess the problem, 
> as usual, is one of semantics.

Yes, I was addressing this from a purely technical level where
transferring money from an account to another entity using an
on-link bank application is currently performed through [technically]
entirely different means compared to using a payment card connected
to the same account.

The hope is [apparently] that open banking APIs will finally unify
the technical side of money transfers, right?

Cheers,
Anders


> 
> Banking originally applied to depository financial institutions (DFI) only.
> The banks were fiduciary holders of funds on the behalf of depositors.
> That is the basis for the financial regulations of the first 1/3 of the 20th century.
> Customers issued bank drafts (checks) against their funds, those were payments to the holder of the draft.
> Bank cards allows account holders access to their funds 24x7 at ATMs.
> 
> Consumer payments originally applied to credit card accounts which were approved drafts signed by the holder of the account.
> This started to change with the initiation of MOTO - mail order telephone order - payments.
> But the big change occurred when banks learned that they could make more money from fees than from deposits.
> 
> Today i guess i would say that "banking" is anything that the account holder initiates on his own behalf.
> Payments are anything that an FI does against a user account that does not have an immediate consumer draft as back up.
> 
> 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.
> Check some of Ross Anderson's articles if you disagree with that statement.
> It seems to date that all apis approved by the banks are in furtherance of such an movement.
> In particular that means that if an aggregator can "write" to the bank, it is no long in the realm of "banking".
> 
> Peace ..tom
> 
> On Sun, Nov 12, 2017 at 10:27 PM, Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
> 
>     On 2017-11-12 04:14, Tom Jones wrote:
> 
>         i am not sure about the eu, but in the us the ach payment method is not constrained by any dollar limit.
>         ANSI X9.59 addressed limits and user consent. AFAICT there is no protection for users in UK open banking or FAPI.
>         It's all banks all the way down.
>         Now if we could find a way to make it a claim, then OpenID can handle it.
> 
> 
>     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.
> 
>     A "visual" of that could be taking a peek at these URL's
>     https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant <https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant>
>     https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf <https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf>
>     which address the same use case.
> 
>     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).
> 
>         Peace ..tom
> 
> 
>     Cheers,
>     Anders
> 
> 
>         On Fri, Nov 10, 2017 at 10:28 PM, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net> <mailto:openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>> wrote:
> 
>              Dear payment aficionados,
> 
>               From what I can deduct, FAPI currently supports a single payment method ("transfer"):
>         https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default <https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default> <https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default <https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_005.md?fileviewer=file-view-default>>
> 
>              After going a bit deeper into the matter including a brief study of the STET PSD2 API (https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html <https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html> <https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html <https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html>>), 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.
> 
>              Comments?
> 
>              Thanx,
>              Anders Rundgren
>              _______________________________________________
>              Openid-specs-fapi mailing list
>         Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net> <mailto:Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>>
>         http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi> <http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi>>
> 
> 
> 
> 



More information about the Openid-specs-fapi mailing list