[Openid-specs-fapi] Open Banking NG
anders.rundgren.net at gmail.com
Wed Oct 30 15:49:05 UTC 2019
This picture from OBIE shows a payment scenario that is very far from Apple Pay:
Yeah, using various kinds of "workarounds and fixes" it can surely be improved, but will that really scale?
I have updated the "Dual-mode" Open Banking API proposal which if implemented should make Open Banking payments entirely "on par" with Apple Pay but with the added advantage that it builds on A2A (Account-to-Account) transactions which also is compliant with P2P (Person-to-Person) payments:
To make the proposal more acceptable I have introduced an (optional) TTP role which (unlike PIS) is already known by payment professionals; the Payment Gateway.
On 2019-10-22 07:16, Anders Rundgren wrote:
> A months has passed and it begins looking quite promising:
> Updated: https://cyberphone.github.io/doc/saturn/openbanking-api-for-saturn.pdf
> On 2019-09-21 10:26, Anders Rundgren wrote:
>> This is probably not a use case people subscribed to this mailing list is particularly interested in.
>> However, there are a couple of reason why this is a relevant issue:
>> - If the bank can use the API themselves it will likely be better maintained
>> - If the consumer payment market rather prefers schemes like Swish, TWINT, MobilePay https://empsa.org/ , <https://empsa.org/> FAPI and similar Open Banking APIs could fall in importance
>> FWIW, I have just started (yesterday...) to investigate how Open Banking APIs could work in a local scenario:
>> Swedbank uses the Berlin Group API but I guess the differences (on a higher level) compared to FAPI are not that big.
>> Anyway, since I'm not versed in OAuth2, I wonder if anybody out there have any ideas how to "patch" OAuth2 in such a way that an Open Banking API implementation could work in both local and remote mode without moving [too] many parts? Local mode = trusted service not needing user consent.
More information about the Openid-specs-fapi