Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BankAPI

github.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: BankAPI

#81

Post by trentnelson »

JoelJacobson wrote: post #48
infinii wrote: post #17

From the docs, I can't figure out how this is "decentralized". All I see are encrypted and compressed.

Author here. It's decentralized because the FromBank and the ToBank communicates directly over the Internet using TCP/IP+HTTPS+OpenPGP, which is different from a centralized communication system like SWIFT, where the FromBank would first send the message to ToBank's SWIFT address (so called "BIC"), and wait for ToBank to check their SWIFT "inbox". Compare: FromBank ToBank (BankAPI, decentralized) vs. FromBank SWIFT T…

What happens when the beneficiary bank can't be contacted? Their servers may be down, they may be getting DDoSed, a production upgrade may have gone wrong and they're inadvertently dropping all messages.

That lumps a whole lot of complexity on FromBank, if the onus is on them to ensure ToBank correctly received the payload.

SWIFT takes care of all of this. You also have to guarantee to be connected to the SWIFT network for at least 7 hours per day to process your inbox, and new banks get silo'd in a test area for two months where they have to prove their systems are functioning properly within the SWIFT env before they're connected for real.

As long as FromBank gets its confirmation when it posts to SWIFT, job done. SWIFT takes care of ensuring it gets to ToBank.

Re: BankAPI

#82

Post by twic »

JoelJacobson wrote: post #67
lorddoig wrote: post #61

Earlier quoted context omitted.

Helpful. Are you using this in production with European banks? I saw that on one of the interactive maps on your site there's no line to/from the UK, which is hardly surprising if you are - I would be staggered if they got on board with anything outside their little circle. Are banks in mainland Europe open to this kind of innovation?

Yes, it's in production by some banks and financial institutions in Europe. Most banks are still using SWIFT though. I think the main reason why BankAPI has been accepted, is actually the lack of innovation. Banks are in general very skeptic to new "unproven" technology, but as BankAPI relies on old standards like TCP/IP, OpenPGP, RSA, SHA512 and HTTPS, there is nothing "unproven" in it to be afraid of.

In my few years in finance, i never came across anyone using SWIFT. It was all SFTP and the occasional HTTPS POST, with all the key distribution done manually.

But then, i didn't work in anything in the area of settlement or trade execution - it was in the general area of equities advice, so we moved research, trade ideas, restricted lists, prices, performance calculations, etc.

Given that SFTP and HTTPS are doing the job mostly adequately, i'm not sure why i'd adopt BankAPI (or rather, layer BankAPI on top of the HTTPS i already have). What value does it add?

Re: BankAPI

#83

Post by JoelJacobson »

twic wrote: post #82
JoelJacobson wrote: post #67

Earlier quoted context omitted.

Yes, it's in production by some banks and financial institutions in Europe. Most banks are still using SWIFT though. I think the main reason why BankAPI has been accepted, is actually the lack of innovation. Banks are in general very skeptic to new "unproven" technology, but as BankAPI relies on old standards like TCP/IP, OpenPGP, RSA, SHA512 and HTTPS, there is nothing "unproven" in it to be afraid of.

In my few years in finance, i never came across anyone using SWIFT. It was all SFTP and the occasional HTTPS POST, with all the key distribution done manually. But then, i didn't work in anything in the area of settlement or trade execution - it was in the general area of equities advice, so we moved research, trade ideas, restricted lists, prices, performance calculations, etc. Given that SFTP and HTTPS are doing th…

Author here.

BankAPI is actually using HTTPS, but doesn't depend on SSL alone, as the files/messages are also encrypted/signed using OpenPGP. This means banks would not have to trust all the CAs who issue SSL-certificates, as the OpenPGP public keys are imported once for each bank you wish to communicate with, and won't change unless you explicitly update them.

The value it adds is the two layers of security (HTTPS+OpenPGP) and the "DeliveryReceipt" which makes it possible for both parties (the sending and the receiving bank) to prove they did send and did receive all files/messages sent over BankAPI.

Re: BankAPI

#84

Post by JoelJacobson »

Domenic_S wrote: post #58
christiangenco wrote: post #50

Earlier quoted context omitted.

> The decentralized design of BankAPI protocol ensures noone controls it, noone owns it, noone can shut it down, just like the Internet. The un-innovative design of BankAPI protocol ensures noone can critizise it, as there is nothing new invented, it's just a combination of existing well proven technologies. I don't think I'm comfortable with the 1960s singer-songwriter Peter Noone having this much control of your sy…

https://github.com/trustly/bankapi/pull/2

Thanks for fixing!

Re: BankAPI

#85

Post by JoelJacobson »

Roonerelli wrote: post #15

Interesting project More and more financial institutions are starting to implement messaging using the FIX protocol http://www.fixtradingcommunity.org/pg/main/what-is-fix

You could with benefit send FIX messages over BankAPI, as it doesn't define the content of the messages transferred.

Re: BankAPI

#86

Post by [deleted] »

xedarius wrote: post #3

As far as I know banks tend to prefer dedicated lines rather than relying on the internet, but I guess that isn't always available.

[deleted]

Re: BankAPI

#87

Post by JoelJacobson »

trentnelson wrote: post #81
JoelJacobson wrote: post #48

Earlier quoted context omitted.

Author here. It's decentralized because the FromBank and the ToBank communicates directly over the Internet using TCP/IP+HTTPS+OpenPGP, which is different from a centralized communication system like SWIFT, where the FromBank would first send the message to ToBank's SWIFT address (so called "BIC"), and wait for ToBank to check their SWIFT "inbox". Compare: FromBank ToBank (BankAPI, decentralized) vs. FromBank SWIFT T…

What happens when the beneficiary bank can't be contacted? Their servers may be down, they may be getting DDoSed, a production upgrade may have gone wrong and they're inadvertently dropping all messages. That lumps a whole lot of complexity on FromBank, if the onus is on them to ensure ToBank correctly received the payload. SWIFT takes care of all of this. You also have to guarantee to be connected to the SWIFT netwo…

We are already using SWIFT for much of our messages from/to banks, but it comes with a high cost and a lot more complexity than BankAPI, as messages are not sent directly from A to B, but from A to SWIFT, and then B must check their SWIFT "inbox" to receive the message from A.

With BankAPI, the response from the request comes directly from the beneficiary bank, meaning you know in real-time the message has been delivered. Compared with SWIFT, you only know SWIFT has received the message in real-time.

If the beneficiary bank can't be contacted for what ever reason, the sending bank (FromBank) simply keeps on trying until the beneficiary bank (ToBank) are back online again. The problem with DDoS is a valid concern, but given the banks Internet banking services are also accessed by the banks users via the Internet, they are already dependent on the Internet.

If you don't need real-time messaging and if cost nor complexity is a concern, then you probably won't find BankAPI interesting.

Post reply on HN