4 ms·

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 purpos

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).
- GorgeRonde 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. Makes sense, at least on a technical level. Ditto if I try to place myself as proxy between a business and is PSP. But let me express doubts by referring to the PSD2[1] itself. TL;DR -> I'm not sure offering my product as a container disqualifies it from being a service from a legal standpoint. > Negative scope This Directive shall apply to none of the following: ... services provided by technical service providers, which support the provision of payment services, without them entering at any time into possession of the funds to be transferred, including processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services; Yet the definition of a payment service (last page of the document[1]), seems to indeed indicate such a container would be a payment service. > ANNEX PAYMENT SERVICES (DEFINITION 3 IN ARTICLE 4) ... Execution of payment transactions where the consent of the payer to execute a payment transaction is given by means of any telecommunication, digital or IT device and the payment is made to the telecommunication, IT system or network operator, acting only as an intermediary between the payment service user and the supplier of the goods and services. Here is how I understand this: - if I'm offering a database hosting service that happens to be used in a payment system, I'm not tied to the PSD2 (too low level). - however if I manage this data at the semantic level of a payment system, I'm a payment service not matter how far I try to get from what a "service" technically is. Now, here is what doesn't hold with this feeble interpretation: Under these terms, an open-source client to a european PSP (there are many on GitHub) should be regulated by the PSD2... Where do you draw the line ? [1]: PSD2 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32007L0064 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...

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).

GorgeRonde 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. Makes sense, at least on a technical level. Ditto if I try to place myself as proxy between a business and is PSP. But let me express doubts by referring to the PSD2[1] itself. TL;DR -> I'm not sure offering my product as a container disqualifies it from being a service from a legal standpoint. > Negative scope This Directive shall apply to none of the following: ... services provided by technical service providers, which support the provision of payment services, without them entering at any time into possession of the funds to be transferred, including processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services; Yet the definition of a payment service (last page of the document[1]), seems to indeed indicate such a container would be a payment service. > ANNEX PAYMENT SERVICES (DEFINITION 3 IN ARTICLE 4) ... Execution of payment transactions where the consent of the payer to execute a payment transaction is given by means of any telecommunication, digital or IT device and the payment is made to the telecommunication, IT system or network operator, acting only as an intermediary between the payment service user and the supplier of the goods and services. Here is how I understand this: - if I'm offering a database hosting service that happens to be used in a payment system, I'm not tied to the PSD2 (too low level). - however if I manage this data at the semantic level of a payment system, I'm a payment service not matter how far I try to get from what a "service" technically is. Now, here is what doesn't hold with this feeble interpretation: Under these terms, an open-source client to a european PSP (there are many on GitHub) should be regulated by the PSD2... Where do you draw the line ? [1]: PSD2 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32007L0064 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...