eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
371 stars 54 forks source link

Integration in Open Banking APIs #104

Open cyberphone opened 6 months ago

cyberphone commented 6 months ago

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 ob2 li 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 commented 4 months ago

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 commented 3 months ago

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 commented 3 months ago

@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. ob-vs-wallet-ux li

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.