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

71–80 of 87 posts

Re: BankAPI

#71

Post by contingencies »

runeks wrote: post #54
contingencies wrote: post #27

Earlier quoted context omitted.

... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as…

> Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. The ability of the US to seize USD transaction has nothing to do with any control they might have over SWIFT. All USD transfers -- even USD transfers between two EU citizens -- hapen via a US bank, because only US banks can have a USD balance.…

"only US banks can have a USD balance".

There are USD balances right across the world. Some of them are backed with cash (really!). That's fundamentally because, unlike bitcoin or company shares, currency is what's known as a 'non-consolidated' asset: ie. there is no central ledger anywhere in the world with a complete list of who owns every piece of currency on issue, like exists for Bitcoin on the blockchain.

Re: BankAPI

#72

Post by lorddoig »

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.

I find that quite amazing. There are a few services around that talk to UK banks, and every single one screen-scrapes to get it done (yes, including MITMing your auth creds) because the banks here would never implement a public API.

I've heard of a proper API once - it was only available to corporate account holders with turnover of £3m+ and the bank had to QA your code.

And yet when I took them to task for validating user passwords with `/^[\d\w]{8,16}$/` they refused to see a problem.

Re: BankAPI

#73

Post by spacefight »

PeterisP wrote: post #64
spacefight wrote: post #38

Earlier quoted context omitted.

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…

All valid facts - then just don't call the page pricing. Call it "enquiry" or "contact" or whatever...

Re: BankAPI

#74

Post by TamDenholm »

skeoh wrote: post #68
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?

I'm afraid i didnt get that far, to my knowledge theres no use for it outside the banking system. The example above is of an MT999 which is to send generic messages to and from systems, other codes do other things, have a google, theres a bunch of info on it.

Re: BankAPI

#75

Post by runeks »

JoelJacobson wrote: post #66
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.

I did, but it doesn't make sense in the context of the first one (it doesn't matter that peers may accept longer keys if everyone must use 2048 bit keys). But with your correction it makes sense.

I'm still interested in the reasoning behind accepting 2048 bit RSA keys instead of setting a 3072 bit minimum, which corresponds to AES128 in security[1][2].

[1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p... (Page 64, Table 2)

[2] http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/k...

Re: BankAPI

#76

Post by runeks »

contingencies wrote: post #71
runeks wrote: post #54

Earlier quoted context omitted.

> Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. The ability of the US to seize USD transaction has nothing to do with any control they might have over SWIFT. All USD transfers -- even USD transfers between two EU citizens -- hapen via a US bank, because only US banks can have a USD balance.…

"only US banks can have a USD balance". There are USD balances right across the world. Some of them are backed with cash (really!). That's fundamentally because, unlike bitcoin or company shares, currency is what's known as a 'non-consolidated' asset: ie. there is no central ledger anywhere in the world with a complete list of who owns every piece of currency on issue, like exists for Bitcoin on the blockchain.

You are right, I should have said "only US banks can have an electronic USD balance".

For electronic currency, there is a central ledger (for USD it's the Federal Reserve).

Re: BankAPI

#77

Post by JoelJacobson »

runeks wrote: post #75
JoelJacobson wrote: post #66

Earlier quoted context omitted.

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.

I did, but it doesn't make sense in the context of the first one (it doesn't matter that peers may accept longer keys if everyone must use 2048 bit keys). But with your correction it makes sense. I'm still interested in the reasoning behind accepting 2048 bit RSA keys instead of setting a 3072 bit minimum, which corresponds to AES128 in security[1][2]. [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p.…

Quite many seems to be using 2048 bits RSA-keys for SSL- certicaties:

openssl s_client -connect www.google.com:443 Server public key is 2048 bit openssl s_client -connect www.twitter.com:443 Server public key is 2048 bit openssl s_client -connect www.hsbc.com:443 Server public key is 2048 bit openssl s_client -connect www.citibank.com:443 Server public key is 2048 bit

I don't know the limitations in all the legacy bank systems around the world, but I know my personal OpenPGP smart-card is limited to 3072 bits, but that card is quite modern. Maybe the limits for legacy systems is even worse.

The System Design supports multiple keys per bank, so if a stronger key length is required, keys can easily be upgraded in the future.

But, I agree the strongest key length possible should be used if possible, which is 4096 bits according to the OpenPGP specs.

We will update the specs accordingly.

If any bank for some reason cannot support 4096 bits, then I think it's fair to require at least 2048 bits, as that key length is used by a lot of high profile websites, including banks, already today. (see above list)

Re: BankAPI

#78

Post by JoelJacobson »

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.

There is a system test which tests all components together, see demo.sh and demo-bankapi.sh.

Re: BankAPI

#79

Post by JoelJacobson »

contingencies wrote: post #27
wclax04 wrote: post #14

Earlier quoted context omitted.

IIRC, thats mostly done using SWIFT [1] [1] http://en.wikipedia.org/wiki/SWIFT_message_types

... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as…

Author here.

Thanks for a well written description and background of SWIFT, I think it is accurate.

I have a question on this paragraph:

>While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more ambitious ideas forming in this area check out http://ifex-project.org/

Does "for a project like this" refer to SWIFT or BankAPI? If SWIFT, then I understand. But if BankAPI, then you have misunderstood, because it does not "leaves the trust and reputation aspects to manual negotiation", since it's decentralized and peer-to-peer (or in this context bank-to-bank), just like a lot of other successful peer-to-peer technologies of which you mentioned one.

Re: BankAPI

#80

Post by contingencies »

JoelJacobson wrote: post #79
contingencies wrote: post #27

Earlier quoted context omitted.

... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as…

Author here. Thanks for a well written description and background of SWIFT, I think it is accurate. I have a question on this paragraph: >While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more…

What I meant by "a project like this" was a concrete, functional alternative to existing status-quo systems, with SWIFT as the implied primary target for forced deprecation.

I think banking is an artificial industry, one that doesn't really have to exist. I believe that money that is state issued, electronically issued, trust that can be quantified, reputation and physical goods are all equally valid assets for forward-looking exchange protocols. I believe that any distinction between participants is farcical and that risk management models, encryption preferences, topology specification and other qualitative decisions regarding deployment must be left out of scope.

To clarify my original comment further, I do think that BankAPI, just at a glance, is probably focusing too much on the conventional world of banking rather than looking at the big picture ... which has nothing to do with banks and everything to do with a potential revolution in the way we organize society, removing anachronistic middle men and vested interests who consistently fail to demonstrate any meaningful reason for being while extracting vast quantities of wealth from society at large and encouraging the continuation of a socio-political and economic trajectory that will see our environment destroyed within a generation.

Post reply on HN