Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Banks are already processing payments. When you put your credit card in your bank's ATM, the ATM is managed by the bank. It connects to your bank server and all the authorisation and processing is being done by the bank. Visa and mastercard provide connection to other banks. When you put your card in another bank's ATM or buy something in a business associated with another bank.

Getting ride of the Visa/Mastercard duopoly would mean that all banks must connect to all other banks, which they do not want to do, believe me. That would be an administrative hell for them. Which is why they've been putting up with those two for so long. These are the google of banks. They are convenient.

The alternative would be some sort of joint venture between all the banks. The result would less fees for the banks but no benefits for the client as the bank would keep the margin and it would still be a privacy hell.

Another alternative is a public utility. But a lot of people will be as uncomfortable providing their payment data to the government.



> The alternative would be some sort of joint venture between all the banks. The result would less fees for the banks but no benefits for the client as the bank would keep the margin and it would still be a privacy hell.

This is what happens in India. UPI (unified payment interface) was launched by NPCI which is kind of a joint venture between the regulator and banks. In an abstract sense, the bank processing the payment does connect with every other bank via NPCI.

The underlying rails are an older infrastructure of IMPS[1] which is the interbank money transfer system.

I do not agree with the privacy hell part. When bank transfers happen, they anyway have to do the required checks with the other banks. Frankly, people in my circle never even cared if it could be a privacy issue for us.

On another note, there was always incentive to launch NPCI in india because 1/ The infra is relatively newer so it was easier to do (java I think) 2/ Almost all banks' software was built by Infosys/TCS etc. (in java) and that meant the ones integrating would be the same parties who practically used the same architecture 3/ Visa/Mastercard did not have that kind of penetration in 2010 so settlements were a real issue faced by every bank.

In US or European case, the issue seems bigger because the problem is half solved by Visa/Mastercard, so there is a bit of inertia to solve the same problem again.

[1]: https://www.npci.org.in/PDF/npci/upi/Product-Booklet.pdf


> Getting ride of the Visa/Mastercard duopoly would mean that all banks must connect to all other banks, which they do not want to do, believe me. That would be an administrative hell for them.

What would be so strange about that?

https://en.wikipedia.org/wiki/Single_Euro_Payments_Area


Aren't most SEPA transfers not settled directly bank-to-bank but through STEP2? https://en.wikipedia.org/wiki/EBA_Clearing#STEP2

That said, in a system replacing VISA/MasterCard (which I personally believe is a goal worth working toward), it seems like the easiest way would be to connect all the existing national clearing systems (many of these already have instant payments on their own - Fedwire in the US, STEP2 in the Eurozone, Zengin in Japan, etc etc) in a two-tier system.


Oh, my point was not confirming the premise of the parent in that all banks would need to connect to all other banks, but that it would not be such a hard feat to get rid of VISA/Mastercard for this kind of processing.


> would mean that all banks must connect to all other banks

I think the EU's getting there with open banking directives like the PSD2:

"the provision of a standardised and reliable access interface to payment accounts (i.e. an application programming interface, API)" https://www.ecb.europa.eu/paym/intro/mip-online/2018/html/18...


A pseudo-public joint venture model is viable in internet telecoms (eg ICANN), so why not in payment clearing?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: