Integration in Open Banking APIs

[cyberphone]

There is no doubt that the current Open Banking architecture has served us well. However, for dealing with a multitude of new applications like wallets as well as legacy systems like EMV, the current approach (putting everything in one big soup), has proved to be very costly, slow, and cumbersome; it has effectively ran out of gas. To cope with this, a V2 architecture has been proposed. Through the use of loose coupling, applications can be developed independently of the core, including being supplied by third parties. In fact, applications may be supplied as Docker images or as boxed systems, potentially deployable in any compliant bank.
https://cyberphone.github.io/doc/research/revised-open-banking-architecture.pdf

Although this may look like a total redesign, it is in practice rather more like a refactoring of existing components.

The purpose with extending the scope of Open Banking, is to make Open Banking a part of banks' core business, rather than something pushed on them by regulators. The expanded scope will also cope with person-to-person payments.

[cyberphone]

It might be of interest knowing that E&Y consulting is on the same track:
https://thepaypers.com/expert-opinion/how-will-open-finance-reshape-financial-services-of-the-future--1266586

This should ideally combine APIs, modular technology architecture, and micro-services to deliver discrete, individually deployable, and vendor-agnostic components. By plugging-and-playing components and technology accelerators, banks could reduce build effort, cut development cost, and scale more effectively

[earizon]

Correct me, but in the context of the ARF, at least in the technical context of the ARF, Open Banking "maps" broadly to making sure that standard protocols are compatible with the FAPI. I had no much time to dig around but basically it means applying security rules like encrypting all communications end-to-end. Probably it also means many other "details" such as getting sure that presented credentials trigger "idempotent" results (for example, adding some expected metadata about initial and final state to anything related to "moving money").

[cyberphone]

@earizon You are correct, Open Banking (at least the UK version) builds on FAPI. Although FAPI is fine it was never designed to be used with wallets; FAPI rather builds around the PISP concept.

In the Open Banking case the user must select bank or type in an account number in order for the PISP to contact the proper bank which turn asks the user to authorize the transaction using their proprietary banking application and associated unique UX.

Using a wallet you would typically get the same experience as with Apple Pay which in turn builds on the established card metaphor. This also means that the user gets an identical UX regardless of who have issued the payment credential.

The APIs for these two approaches are entirely different.

[digeorgi]

Thank you for your submission.
Open banking refers mainly to open APIs between different financial actors, on behalf of the customer. This involves authenticating the User. The EUDI wallet supports authentication of the User, Several payment use cases are being studied and implemented by the LSPs, therefore further implications on specific services requested from the EUDI Wallet may be specified in the future.

[cyberphone]

Thanx for your feedback!
@earizon @digeorgi This is the only public "EUIDW-4-Payments" specification I have been able to find: https://github.com/digitallabor-berlin/eudiw-sca/blob/main/openbanking-r2s.md
It does not build on FAPI. It seems to (indirectly) be supported by the OpenID4VP folks: https://github.com/openid/OpenID4VP

I find this specification more than a little bit strange.