6 ms·

> 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,

> 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 aggregated information, before or after processing, about one or more payment accounts. If your product doesn't do this, e.g. credit scoring using the user's bank transactions instead of credit bureaux, then you're not performing a regulated activity, therefore the regulator has nothing to authorise, and you can't enjoy the resulting entitlement of API access. This means there are whole classes of (unregulated) applications that won't be allowed to exist by banks if they adopt the position of granting access only to regulated entities. > this requires a certification and a load of other nonsense akin to PCI-DSS AIS and PIS have become regulated activities as a result of PSD2. This is not the same as PCI-DSS. Becoming a (P|A)ISP means becoming supervised by the local regulator as an authorised financial institution. This involves a lot of paperwork, a £1,500 application fee, insurance, fees for any professional services you needed to complete the application (lawyer), and 3 months (longer if your application is incomplete or has other issues). > for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requires even more paperwork. And €50,000 own capital requirements. > I also said APIs because the regulation does not mandate any kind of API format, so every bank has their own with different capabilities as far as what data is returned and in which format. Some of them are truly awful. This is true at the moment for Europe but notionally incorrect for the 9 largest banks in the UK, which are subject to parallel domestic measures ordered by the Competition and Markets Authority. There is a spec, but there are many problems with the governance, implementation, etc.

abraae 8y ago
To be honest those requirements sound perfect for a scrappy startup. Just enough of a moat to deter 99% of drive by hackers, but within the reach of any reasonably serious startup. - £1,500 application fee - €50,000 own capital requirements If you're aiming to play in this league you really should be able to scrape together this kind of money. - 3 months wait Can also be seen as a 3 month delay imposed on your competitors. Of course if you're aiming to use the API for your own personal needs only- then yeah, these requirements suck.
- jacobush 8y ago
  Except, many interesting things you can't do, because those are not AIP things.
repolfx 8y ago
From what I've heard the main problem is banks are afraid popular API access would overload their mainframe-era systems that don't scale and can't scale.
- Nursie 8y ago
  It's more that they'd prefer to keep the competition out of their datastores, AFAICT
- deadbunny 8y ago
  Which is utter nonsense. They already have APIs, they're used in their mobile apps.
  - repolfx 8y ago
    That's not an API, that's a private protocol for which they can easily anticipate and control load (e.g. by pushing changes to their apps).
    - Rjevski 8y ago
      They can just provide them as-is, with no guarantees, and a big "things can and will break" disclaimer. This will be unusable for commercial usage, but will allow power users to automate their finances.
    - deadbunny 8y ago
      All the banks I'm with use rest APIs in their apps (you can see this by MITMing the traffic), no "private protocol" whatever the hell that is. As for controlling load, I'm not sure I follow. If you have 1m people with the mobile app installed and all of them decide to check their balance at the same time your systems are going to crumble if you've only provisioned for 10,000. Web/Mobile banking doesn't talk to the mainframes directly, it's essentially a caching layer which gets committed later when the mainframe does it's job. Not much different from your average web app just with longer delays.
      - 8y ago
GorgeRonde 8y ago
I'm actually investigating the ins and outs of building a product that interposes between e-money gateways and businesses implementing them. It has three purposes: - 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 ?
- Rjevski 8y ago
  The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP. Not an issue if you're doing screen-scraping though, I agree (although in that case, do you even care about AISP certifications? You can so scraping-as-a-service and in fact there is an entire industry around this already).

abraae 8y ago

To be honest those requirements sound perfect for a scrappy startup. Just enough of a moat to deter 99% of drive by hackers, but within the reach of any reasonably serious startup. - £1,500 application fee - €50,000 own capital requirements If you're aiming to play in this league you really should be able to scrape together this kind of money. - 3 months wait Can also be seen as a 3 month delay imposed on your competitors. Of course if you're aiming to use the API for your own personal needs only- then yeah, these requirements suck.

jacobush 8y ago
Except, many interesting things you can't do, because those are not AIP things.

repolfx 8y ago

From what I've heard the main problem is banks are afraid popular API access would overload their mainframe-era systems that don't scale and can't scale.

Nursie 8y ago
It's more that they'd prefer to keep the competition out of their datastores, AFAICT
deadbunny 8y ago
Which is utter nonsense. They already have APIs, they're used in their mobile apps.
- repolfx 8y ago
  That's not an API, that's a private protocol for which they can easily anticipate and control load (e.g. by pushing changes to their apps).
  - Rjevski 8y ago
    They can just provide them as-is, with no guarantees, and a big "things can and will break" disclaimer. This will be unusable for commercial usage, but will allow power users to automate their finances.
  - deadbunny 8y ago
    All the banks I'm with use rest APIs in their apps (you can see this by MITMing the traffic), no "private protocol" whatever the hell that is. As for controlling load, I'm not sure I follow. If you have 1m people with the mobile app installed and all of them decide to check their balance at the same time your systems are going to crumble if you've only provisioned for 10,000. Web/Mobile banking doesn't talk to the mainframes directly, it's essentially a caching layer which gets committed later when the mainframe does it's job. Not much different from your average web app just with longer delays.
    - 8y ago

GorgeRonde 8y ago

I'm actually investigating the ins and outs of building a product that interposes between e-money gateways and businesses implementing them. It has three purposes: - 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 ?

Rjevski 8y ago
The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP. Not an issue if you're doing screen-scraping though, I agree (although in that case, do you even care about AISP certifications? You can so scraping-as-a-service and in fact there is an entire industry around this already).