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

61–70 of 87 posts

Re: BankAPI

#61

Post by lorddoig »

JoelJacobson wrote: post #43
lorddoig wrote: post #16

What's the motivation for this? Is it coming from inside the industry/is it a suggestion/fun project? I'm don't understand the purpose - it's all about transmission, not data. Banks could sure do sure do with a standardised API, but is interbank message encryption a problem needing solved? I've haven't heard anything like that. The author is very sure of it's production-readiness. If this transpires to be true, then…

Author here. That's a good question. Please see: https://github.com/trustly/bankapi/blob/master/doc/rationale...

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?

Re: BankAPI

#62

Post by PeterisP »

drivingmenuts wrote: post #35
jacquesm wrote: post #6

Earlier quoted context omitted.

More and more traffic to and from banks goes over the public internet, it is a matter of time before 'dedicated lines' will be limited to the military and that's pretty much where the internet originated so at a guess even they are using the internet except for when it is extremely critical to get traffic from 'a' to 'b' with minimum latency.

Seems like dedicated lines would be more secure. More expensive, too, but sometimes security should trump expense. or How stupid do you have to be to trust core financial information to public communication methods?

Dedicated lines are exactly as secure as the internet - i.e., not secure, so there's no difference on that regard. From a security viewpoint, they're treated as unsecure as a number of third parties (the network providers and such) may have access to it; so you have to encrypt all data in transit in the exact same manner as you would on an internet connection.

In finance, you get dedicated lines for bandwidth/latency guarantees (i.e., no congestion out of your control) or for redundancy and fault tolerance; not for security.

Re: BankAPI

#63

Post by runeks »

chousuke wrote: post #60
runeks wrote: post #56

Earlier quoted context omitted.

> This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. According to Trustly themselves, it is used by 45 banks spread out over 7 EU countries (Sweden, Finland, Denmark, Estonia, Poland, Italy and Spain): https://trustly.com/en/#map-holder

Huh. That seems to include all the (major?) banks in Finland. At least I don't know of a bank in Finland that isn't on that list.

I was surprised too. It includes the three largest banks in Denmark as well.

Re: BankAPI

#64

Post by PeterisP »

spacefight wrote: post #38
ThomPete wrote: post #30

Earlier quoted context omitted.

Yes some of the largest Northern European banks. https://trustly.com/en/

I loooked at their pricing page on https://trustly.com/en/pricing/ - not a single price is there. Come on guys...

If you publish any kind of price, that affects your negotiation options if you want to do individual pricing/haggling for each customer.

Also, a multitude of factors affect the 'true' price including various risk estimates of your company, and it would be counterproductive to say "factor X, as measured by Y, gives you a price increase/decrease of Z", as that would just result in gaming the measurement and misleading about the nature of your business.

Re: BankAPI

#65

Post by malgorithms »

TamDenholm wrote: post #29

I dont know if anyone is interested, but someone once asked me to look into the SWIFT messaging system, i'd never done anything with banking before. I made a little once page app as i learned it which breaks it down to what everything does. It doesnt do anything except send to a validation API, which currently is down cuz i've not touched it in months, but i figured some people might find this interesting. http://lab…

Cool - the notes are very educational. I love this kind of thing: "This must NOT be more than 12 characters long and character 9 cannot be X"

Re: BankAPI

#66

Post by JoelJacobson »

runeks wrote: post #57

> 1. All parties MUST use a key length of 2048 bits for their RSA keys. What is the point of this? Seems to me there'd be no problem in using 3072 bit RSA keys, which makes more sense given that the lowest security symmetrical encryption algorithm permitted for use is AES128, and the difficulty of breaking AES128 is roughly equivalent to breaking 3072 bit RSA.

Did you not read the next sentence? "Implementations MAY accept longer keys.". It should say "of at least 2048 bits", I'll update the docs.

Re: BankAPI

#67

Post by JoelJacobson »

lorddoig wrote: post #61
JoelJacobson wrote: post #43

Earlier quoted context omitted.

Author here. That's a good question. Please see: https://github.com/trustly/bankapi/blob/master/doc/rationale...

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.

Re: BankAPI

#68

Post by skeoh »

TamDenholm wrote: post #29

I dont know if anyone is interested, but someone once asked me to look into the SWIFT messaging system, i'd never done anything with banking before. I made a little once page app as i learned it which breaks it down to what everything does. It doesnt do anything except send to a validation API, which currently is down cuz i've not touched it in months, but i figured some people might find this interesting. http://lab…

I am interested. After looking up SWIFT I can't really get a grasp on what kind of things you can do with it if you're not a financial institution. Do you have any examples?

Re: BankAPI

#69

Post by judk »

christiangenco wrote: post #50
JoelJacobson wrote: post #43

Earlier quoted context omitted.

Author here. That's a good question. Please see: https://github.com/trustly/bankapi/blob/master/doc/rationale...

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

Indeed it is sad when the object of one's affection turns out to be an illogical prescriptivist.

For a grammar Nazi, you are rather loose with capitalization.

ttp://www.yourdictionary.com/noone#wiktionary

https://www.google.com/search?&q=noone

Re: BankAPI

#70

Post by judk »

tveita wrote: post #26
lorddoig wrote: post #16

What's the motivation for this? Is it coming from inside the industry/is it a suggestion/fun project? I'm don't understand the purpose - it's all about transmission, not data. Banks could sure do sure do with a standardised API, but is interbank message encryption a problem needing solved? I've haven't heard anything like that. The author is very sure of it's production-readiness. If this transpires to be true, then…

They call it "production grade quality", but I don't see a test suite.

Maybe it's production grade F
Post reply on HN