BankAPI

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)

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

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

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

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.

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.

The actual transfers happen by way of so-called US "intermediate" banks, who perform the actual USD transfer. The process is described here: https://bitcoinfoundation.org/2012/12/international-bank-tra...

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.

All security is a trade-off between 'enough security' and expense. There is no such thing as 'absolute security', if dedicated lines are not measurably more secure than the public internet then choosing to route your traffic via the net rather than via dedicated lines is the right decision.

Banks are in general not 'stupid' when it comes to what they do with their data, they try to do their best within the triangle of security, expenses and technical demands.

If you think using 'public communication methods' for the transport of core financial information is stupid then I guess you are also against banks that are connected to the internet using websites, against banks that use 'swiftnet' (SWIFT is a provider of a secure network used to transfer financial information between banks, which - surprise - has been compromised in the past by the NSA and where payments in transit between two other countries has been seized by the USA because those payments violated a US policy).

In the end, at some point a bank will have to trust the wires and the parties that maintain those wires. From a banks point of view an operator like SWIFT and the public internet vary in degree as to their security but which one to use will always be a business decision and as noted above even SWIFT is not 100% secure and might in some ways be less secure than the public internet.

I also wonder how you propose banks communicate with their customers and with their branch offices.

Here is a nice page on the connectivity options a SWIFT partner gives to its customers all the way from DSL to dedicated lines:

http://www.orange-business.com/en/swift-connectivity

And dedicated lines can be tapped too, so in the end the encryption matters more than the physical connection.

The CIA got a lot of info out of the Soviet Union by tapping their military undersea communications cables, which carried unencrypted data as they assumed they were protected.

Sometimes the dangers of public communications methods lead to better security in that you have to consider it rather than assuming you're safe.

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.

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.

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.