Earlier quoted context omitted.
PSD2 and “open” banking is bullshit. I wish this myth would die - it is anything but “open”. If you want to gain access to API s , you need to become an “AISP” (as they are called in the UK), this requires a certification and a load of other nonsense akin to PCI-DSS. This is for read-only access - for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requi…
> If you want to gain access to APIs, you need to become an “AISP” It's more complicated than that. Banks can give unregulated entities access to their APIs, but they don't because IMO providing API access is directly opposed to their interests. If you want to be statutorily entitled to API access you need to be a registered AISP or PISP. Unfortunately what an AIS is is very specific, i.e. showing the account owner a…
- Data synchronization. Usually, either because you're sane, or have legal obligations to do so, you maintain your own ledgers in addition to those provided by the payment service provider. It's hard to do, leads to countless hours of manual maintenance when something goes wrong which of course alienates a (hopefully small) part of your clients.
- Proper handling of a "distributed system". By distributed system I mean a CRUD remote service with asynchronous notifications, not paxos-based phd-level systems. I'm not trying to downplay the difficulty of communicating with "simple" systems like this, quite the contrary. There can fail in quite surprising ways. I'm not even mentioning the fact payment-services have unrollbackable real-world consequences, like money-real. It's really easy to lose money when misusing a payment system.
- Providing a meta-interface to many payment-systems.
-- Migrating from one payment service to another one can turn out to be a multiple-people year-long project for some?/many? businesses. This is even more impactful for startups that manage to break through and need to find a better deal with a different payment service as their user base sky-rockets.
-- In some countries (for instance Morocco), there is no deal between international players in the PSP market (PayPal, Stripe, etc ...) and national banks. To perform electronic payments, you must communicate with the system of a state-controlled entity. Businesses that want to extend their market to these countries must support additional developments, that may well cost them as much as plugging to yet another payment system.
I tried my best reading the PSD2, but I wasn't able to determine if the law applied recursively: for instance, as an AISP (Account Information Service Provider), can I legally aggregate data coming from other AISPs (i.e. with the access to that data being granted to me by the law) ?
Anyway, for technical, UX, and legal reasons (mainly avoiding the 50k€ requirement) I thought it would be better to abandon the idea of proposing my clients access to a remote service but to instead loan them a local service as a brick to place in their own infrastructure (in the form of a container for instance). This service's data would be theirs and stored in their own database. To use it they would configure it with their own API keys to these various payment systems.
What would be the legal requirements under such a configuration ?