
BankAPI - JoelJacobson
https://github.com/trustly/bankapi/
======
runeks
> 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.

~~~
JoelJacobson
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.

~~~
runeks
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...](http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)
(Page 64, Table 2)

[2] [http://www.emc.com/emc-plus/rsa-labs/standards-
initiatives/k...](http://www.emc.com/emc-plus/rsa-labs/standards-
initiatives/key-size.htm)

~~~
JoelJacobson
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)

------
lorddoig
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 I could easily see this spec as a good way to encrypt message-based
data of all kinds. But where does this bank angle come from?

~~~
JoelJacobson
Author here. That's a good question. Please see:
[https://github.com/trustly/bankapi/blob/master/doc/rationale...](https://github.com/trustly/bankapi/blob/master/doc/rationale.md)

~~~
christiangenco
> 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 system.

</snark>

This is a grammatical pet peeve of mine[1], principally because I used to use
it exclusively and was horrified when a girl I liked at the time corrected me.

1\. [http://grammarist.com/spelling/no-one-
noone/](http://grammarist.com/spelling/no-one-noone/)

~~~
Domenic_S
[https://github.com/trustly/bankapi/pull/2](https://github.com/trustly/bankapi/pull/2)

~~~
JoelJacobson
Thanks for fixing!

------
TamDenholm
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://labs.tamdenholm.com/swift/](http://labs.tamdenholm.com/swift/)

~~~
skeoh
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?

~~~
TamDenholm
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.

------
mrweasel
I don't think that's how banking works to be honest. Money move from bank to
bank via the countries central banks if I'm not mistaken. Then the central
bank reconcile everything in batch processes to ensure that banks aren't just
making up money (well more than they are legally allowed to).

Denmark has had a few occasions in the last few years where this has failed
because one bank failed to deliver their transactions one night.

~~~
wclax04
IIRC, thats mostly done using SWIFT [1]

[1]
[http://en.wikipedia.org/wiki/SWIFT_message_types](http://en.wikipedia.org/wiki/SWIFT_message_types)

~~~
contingencies
... 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 a first order of business after
accruing partaking institutions at a speed frankly unbelievable given the
technology of the time. It was billed as a telex replacement.[2] After
recently dispatching with its carefully developed apolitical facade and
banning Iran (after receiving Europe's blessings at the behest of UANI, which
is essentially Mossad + CIA old guard[3]), it pissed off India (who depend on
them for energy security) and raised eyebrows in Russia and China.

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/](http://ifex-project.org/)

[1] Quote from European Data Protection Supervisor in response to FOIA: "since
at least 2001"
[http://www.asktheeu.org/en/request/information_on_financial_...](http://www.asktheeu.org/en/request/information_on_financial_informa#comment-46)

[2]
[http://www.swift.com/about_swift/shownews?param_dcr=news.dat...](http://www.swift.com/about_swift/shownews?param_dcr=news.data/en/swift_com/archived_news/61159_carl_reuterski_ld.xml)

[3]
[https://en.wikipedia.org/wiki/UANI#Leadership](https://en.wikipedia.org/wiki/UANI#Leadership)

~~~
JoelJacobson
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/](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.

~~~
contingencies
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.

------
Roonerelli
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](http://www.fixtradingcommunity.org/pg/main/what-is-fix)

~~~
chollida1
Really, my experience is the opposite. FIX is old, like 1992 old and its
starting to show its age. Not that age is necessarily a bad thing, I just
wanted to point out its age as your comment makes it seem like an up and
coming protocol. My experience is that more and more firms are leaving it.

Its' no longer suitable for market data. Its barley suitable for sending order
messages around. And with the explosion of order types and growth I'm not sure
that's a valid statement anymore.

Its not anywhere near as compressible as binary formats. Many exchanges and
dark pools have already replaced it with binary formats.

What fix does have going for it are quickfix/j and a wealth of knowledge,
which will keep it relevant for a long time, but

~~~
lotsofcows
FIX can operate as a binary, compact ASCII or XML-like protocol. FIX has
support for multicast. FIX has open source Java, .NET and C++ implementations.
It's got a thriving development community and a non-profit, industry-driven
standards body. FIX isn't going anywhere. No buts.

Possibly you haven't looked at it since 1992...

~~~
minimax
But FIX _is_ going away in US equities as all of the major exchanges have
adopted native binary protocols. We still have to deal with it in other asset
classes, but I (as a developer) am not really happy about it. FIX/FAST is a
massive pain in the ass relative to simple binary protocols.

------
iamsalman
With banks considering the switch to the Cloud, how would this specification
address the issue of key management on the Cloud? That's the "key" to Cloud
security. Currently, there are solutions available which are obnoxious for
those who <i>really</i> want security of their data and not just a <i>tick
mark</i> on some data security checklist because key managers CANNOT be hosted
on the Cloud. The dominant approach (CipherCloud for example) is to have an
encryption gateway in-house which encrypts/decrypts/tokenizes on-the-fly
before data leaves for the Cloud. Their approach is to enable support for
popular SaaS apps like SalesForce and archive storage like S3 etc which makes
sense BUT then again, it's dependent on whether the vendor would add support
for more apps or open the API for 3rd party devs to plug in support for other
Cloud apps.

~~~
pharaohgeek
A networked HSM is certainly one approach to solving this. Often, corporations
-- not just banks or financial institutions -- will rent a cage in the same
data center as the cloud provider, and will run a dedicated line from their
cage to the provider. The networked HSM will store all key material, and
whatever sensitive servers/databases/applications are provisioned in the cloud
will leverage it for cryptographic operations.

In theory... 1) The keys never leave the physically-hardened HSM, so they're
"safe", 2) Transmission between the HSM clients and the HSM is done over an
encrypted channel, so that's "safe"

There's always a very high risk of implementing things improperly and negating
any security benefits of this type of setup, but that risk exists with on-prem
infrastructures, too.

~~~
orr94
You forgot to capitalize "Cloud".

------
xedarius
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.

~~~
jacquesm
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.

~~~
drivingmenuts
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?

~~~
jacquesm
> More expensive, too, but sometimes security should trump expense.

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](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.

------
RobinUS2
Are there any banks actually using this? Or is it more like a suggested spec
draft?

~~~
ThomPete
Yes some of the largest Northern European banks.

[https://trustly.com/en/](https://trustly.com/en/)

~~~
spacefight
I loooked at their pricing page on
[https://trustly.com/en/pricing/](https://trustly.com/en/pricing/) \- not a
single price is there. Come on guys...

~~~
PeterisP
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.

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

------
dqmdm2
Is there any potential synergy between this project and Open Transactions?
[http://opentransactions.org/wiki/index.php?title=Main_Page](http://opentransactions.org/wiki/index.php?title=Main_Page)

------
zAy0LfpBZLC8mAC
Why this weird API? I dunno, I would expect exactly two functions, one for
sending a "file", and one for receiving whatever is new in the inbound queue,
with the abstraction taking care of delivering the enqueued files to their
destination!? And maybe a callback API so I don't have to poll for new inbound
"files". Also, I'd expect the abstraction to provide an ordered, lossless
stream, rather than some weird "file sync" which seems to lack all reordering
and replay protection?

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

~~~
JoelJacobson
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
<-> ToBank (SWIFT, centralized)

(FromBank = Bank sending the message) (ToBank = Bank receiving the message)

~~~
trentnelson
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.

~~~
JoelJacobson
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.

------
swah
Simpler than this, I really wish my bank had a github-style webhook support
for so that integration with other services could be great.

------
freyfogle
a similar project:
[http://www.openbankproject.com](http://www.openbankproject.com)

------
peteretep
If it kills Connect:Direct, hooray!

------
mtkd
HN really needs to show a 2nd level to some domains in the headline:

BankAPI (trustly.github.com) not BankAPI (github.com)

Always takes me a moment or two to work out if it's a Github specific link or
a project on Github

~~~
vertex-four
This doesn't link to trustly.github.com though.

~~~
corin_
Worth noting that HN does already have that functionality on a domain-by-
domain basis. Not sure which domains exactly, but in 30 seconds found examples
for blogspot.com, pinboard.in and github.io (example links below)

    
    
      https://news.ycombinator.com/item?id=8256653
      https://news.ycombinator.com/item?id=8249953
      https://news.ycombinator.com/item?id=8252208

------
ThePhysicist
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. Most bank software is still written in Cobol code that they have
invested four decades into and are now too afraid to rewrite or even touch.
So, specifying the requirements for an interbank message system would probably
take them a few years already, and implementing it in a "proper" way -i.e.
confirming to all their regulatory requirements- would take ages (also, they
will probably already have a system for this in place).

That being said, I think for less regulated sectors of the industry this could
be a very interesting project.

~~~
twrkit
I used to work for one of the megabanks. The majority of their credit card
processing is written in Fortran and runs on 20-30+ yr old mainframes. They
don't dare touch it. "If it ain't broke..."

There are certain universities that teach Fortran specifically for companies
like this; any student of Fortran has an automatic offer once they graduate.

~~~
Ecio78
Are you sure it was Fortran and not Cobol? Normally Fortran was used for
academic/math (ForTran stands for Formula Translation, Cobol in busines (Cobol
stands for COmmon Business-Oriented Language).

~~~
JackFr
Fortran found its way into finance because it was the programming language
taught to engineers in school. (These were real engineers -- software
engineers hadn't been invented yet.) If you hired them to build computer
systems you got systems in Fortran unless you specified otherwise.

