PSD2 - kick for banks

The article is of little use for the CIS countries, but you may like it



image



I have been working a lot with the API of various banks lately. There is one reason for this - a new directive called PSD2 (Revised Payment Service Directive). Iā€™ll tell you about her.



Introduction



It all started with companies like PayPal. You register on the PayPal website, it, in turn, picks up your credit card, withdraws money from it when necessary, accumulates deductibles in its accounts, and then on the appointed day ships the entire nth amount of money to the account of the online store. Thus, your credit card remains safe, the online store saves money, which means you save money. It seems everyone is good.



On the other hand, the logical question arises: is the store losing customers who do not have a credit card or do not want to get one for individual purchases on the Internet ?!



And here smaller companies come onto the scene, which take not your credit card, but your bank account. Not even that, your online banking! Now you do not need any credit card, you do not need any PayPal, you do not even need to make any transfers. You simply enter your username and password on the storeā€™s website, and the intermediary will do the rest for you.



You enter data into the form on the website of the online store, the intermediary simultaneously enters the same data into the form of the online bank, and then with the help of the same Selenium clicks here and there in your online bank, thus making a transfer to where necessary. More precisely at his own expense, from where he then also ships all the funds to the accounts of the stores once every couple of weeks.



Of course, with any change in the page of the online bank, all this immediately stops working, which annoys people. But banks rarely change anything, so this rarely happens.

Another thing is that some banks do not really like such a security hole, so they try to block such intermediaries. How successfully and exactly how they do it can be argued for a long time, but the article will drag on.



In general, at the request of workers and workers in these intermediary payment systems, the Council of Europe went forward and issued a directive obliging banks to create an API that would allow everything to be the same as they had done with an online bank, but now only with the help of requests. Banks, of course, were very upset, and even without these regulators, they have enough rules to follow, but there is nothing to do - they need to be created.



Naturally, banks are also not from a timid dozen and sabotage this law in different ways, because they do not get any benefit from it. Yes, there are some exceptions when everything immediately works as it should and the documentation is in place, but in most cases itā€™s just a Texas chainsaw massacre, just not a chainsaw and not in Texas, but emails, calls and curses in front of the screen of your monitor in the office.



They sabotage masterfully. Some simply do not translate their documentation. That is, it is, as it were, but it is not, as it were, because no Google will help translate 90 pages of Spanish technical for some reason. The Spaniards generally live in their own vacuum and do not recognize that there is some kind of international language other than Spanish. Many more lay out the documentation in the form of a YAML file in which there is not a single comment, which is not clear where to send, the names of the fields do not have any standards, and you wonā€™t understand what to sign with which certificate or not to sign anything.



The top of sabotage is the documentation page, where only the endpoints of the API are indicated, but in principle there are no header or body with a description. Not even a POST or GET request is indicated. Of course, the legal department runs after such guys, saying that complaints to the supervisory authority may not entail a fine, but in the future it may lead to excessive attention to this bank. In most cases, this helps, but time goes by.



I knew about the crap banks, now you can write about the law itself.



What is PSD2?



This is a directive issued by the European Commission to improve the online payment market, as well as increase the security of these payments.



In fact, there was still a PSD, but it simply regulated payments between states in the EU, without regulating online payments. Although what online payments in 2007m then.



They took the mentioned PSD as a basis and fastened a dozen chapters to it with the beautiful name ā€œopen bankingā€ (open banking). This ten chapters became a headache for banks and a joy for payment systems (in theory, in fact, banks made a headache for payers too, so as not to suffer.)



PSD2 also regulates client security, saying how and in what way requests should be transmitted, which certificates to use and what can be requested from the bank and what not. That is, for payment you can request a first and last name, as well as a list of user accounts, but you wonā€™t get anything else, even if you ask a lot.



Now you have to request a token from the bank, register as an organization, which can and should perform any actions on behalf of the client, plus you must have a secret key, etc., etc. In general, security has actually grown significantly. Well, the responsibility of both parties, too.



But here, banks are free to add their own layers of security. For example, banks allow you to enter customer data only on the pages of the bank. That is, in any case, you will have to redirect the user to the bankā€™s page, and then return them back to you (okay, Selenium can also help out here, but now the banks can send you fiery greetings and deny access to their API if something is wrong).



Okay, now about the obvious, and not so, pluses



As I said above, security has grown significantly. Now, payment systems do not invent bicycles and do not interact with the motley APIs of banks, but connect to more or less standardized APIs, so everything is fine with security.



Now, if you are a payment system, for example, in Estonia, then you can use the API of European banks to accept payments from European customers. And for this you only need to register as a financial institution, read about a hundred documents and implement all this in your system. However, most of the documentation will be in English, in addition, you will have more or less distinct support from the bank.



And also, if you are a bank outside the EU, then you can join this open banking and your customers will be able to pay with European payment systems.



Well, here you can also write down the pluses that if you are not such a big company to break the prices for transfers and share part with banks, then you can now freely do the same as a big company, because the right to access payments now everyone has equal.



Now about the cons



There is a directive, but the API in its working version is not. The situation is quite common even now, a year after the banks began work on implementation (and, well, yes, they should have started work ...).



The APIs are not completely unified, just like the payment process. That is, you cannot create something universal for all banks, you have to adjust the functionality for requests for each bank separately, which greatly slows down the development.



Even the same bank can have different APIs in different countries. Because each country has its own regulatory bodies that add some kind of ā€œregulationā€ to the process. There you need additional tokens, there you need to authorize the user three times, there is something else ...

Well, now your business of the payment system completely depends on the bank, whose servers can suddenly go down, and while the whole bureaucratic machine runs and starts them again, it may take a day or two, which will deprive your decent earnings. At the same time, you cannot present something to the bank.



That's all.



All Articles