9 ms·

BankAPI

194 points by JoelJacobson 12y ago

TamDenholm 12y ago
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/
- malgorithms 12y ago
  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"
- skeoh 12y ago
  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 12y ago
    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.
RobinUS2 12y ago
Are there any banks actually using this? Or is it more like a suggested spec draft?
- valevk 12y ago
  Never heard of it. The README only link RFCs concerning PGP. I didn't find a draft of standards for protocol itself.
- ThomPete 12y ago
  Yes some of the largest Northern European banks. https://trustly.com/en/ https://trustly.com/en/
  - spacefight 12y ago
    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...
    - drpancake 12y ago
      I think it's excusable for a relatively niche B2B service where there's likely a huge variation in the size of their customers. Price discrimination is hard.
    - PeterisP 12y ago
      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 12y ago
        All valid facts - then just don't call the page pricing. Call it "enquiry" or "contact" or whatever...
xedarius 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      > 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.
iamsalman 12y ago
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 really want security of their data and not just a tick mark 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 12y ago
 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 12y ago
 You forgot to capitalize "Cloud".
ThePhysicist 12y ago
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.
- LinaLauneBaer 12y ago
  I have worked for banks and data centers/bank service providers and have not seen a single line of Cobol but millions Java-LOC and REXX.
  - ShortTimer 12y ago
    REXX was my first introduction to programming for a real production system (at a national bank). It was one of the few usually-available, general-purpose toolsets that you could pretty much rely on to be available for "hacking something together." Fond memories of my REXX days, although I shudder to think of going back..
- twrkit 12y ago
  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 12y ago
    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).
freyfogle 12y ago
a similar project: http://www.openbankproject.com http://www.openbankproject.com
mrweasel 12y ago
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 12y ago
 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 12y ago
 ... 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_informa#comment-46 http://www.asktheeu.org/en/request/information_on_financial_... [2] http://www.swift.com/about_swift/shownews?param_dcr=news.data/en/swift_com/archived_news/61159_carl_reuterski_ld.xml http://www.swift.com/about_swift/shownews?param_dcr=news.dat... [3] https://en.wikipedia.org/wiki/UANI#Leadership https://en.wikipedia.org/wiki/UANI#Leadership
Roonerelli 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
- JoelJacobson 12y ago
  You could with benefit send FIX messages over BankAPI, as it doesn't define the content of the messages transferred.
lorddoig 12y ago
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?
- easytiger 12y ago
  And what does it offer above ssh/ssl on their own?
- mnem 12y ago
  It appears to be from https://trustly.com/en/ https://trustly.com/en/ so perhaps they use it internally and are open sourcing it.
  - lorddoig 12y ago
    I should have checked that before commenting, itchy trigger fingers I suppose. It makes a great deal more sense now.
- tveita 12y ago
  They call it "production grade quality", but I don't see a test suite.
  - judk 12y ago
    Maybe it's production grade F
  - JoelJacobson 12y ago
    There is a system test which tests all components together, see demo.sh and demo-bankapi.sh.
- 12y ago
infinii 12y ago
From the docs, I can't figure out how this is "decentralized". All I see are encrypted and compressed.
- JoelJacobson 12y ago
 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 12y ago
 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 12y ago
 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 12y ago
Simpler than this, I really wish my bank had a github-style webhook support for so that integration with other services could be great.
mtkd 12y ago
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 12y ago
  This doesn't link to trustly.github.com though.
  - corin_ 12y ago
    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
dqmdm2 12y ago
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
peteretep 12y ago
If it kills Connect:Direct, hooray!
zAy0LfpBZLC8mAC 12y ago
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?
runeks 12y ago
> 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 12y ago
  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 12y ago
    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_part1_rev3_general.pdf 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/key-size.htm http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/k...
    - JoelJacobson 12y ago
      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)

194 points by JoelJacobson 12y ago

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/

malgorithms 12y ago
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"
skeoh 12y ago
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 12y ago
  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.

RobinUS2 12y ago

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

valevk 12y ago
Never heard of it. The README only link RFCs concerning PGP. I didn't find a draft of standards for protocol itself.
ThomPete 12y ago
Yes some of the largest Northern European banks. https://trustly.com/en/ https://trustly.com/en/
- spacefight 12y ago
  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...
  - drpancake 12y ago
    I think it's excusable for a relatively niche B2B service where there's likely a huge variation in the size of their customers. Price discrimination is hard.
  - PeterisP 12y ago
    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 12y ago
      All valid facts - then just don't call the page pricing. Call it "enquiry" or "contact" or whatever...

xedarius 12y ago

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 12y ago
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 12y ago
  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 12y ago
    > 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.

iamsalman 12y ago

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 really want security of their data and not just a tick mark 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 12y ago
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 12y ago
  You forgot to capitalize "Cloud".

ThePhysicist 12y ago

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.

LinaLauneBaer 12y ago
I have worked for banks and data centers/bank service providers and have not seen a single line of Cobol but millions Java-LOC and REXX.
- ShortTimer 12y ago
  REXX was my first introduction to programming for a real production system (at a national bank). It was one of the few usually-available, general-purpose toolsets that you could pretty much rely on to be available for "hacking something together." Fond memories of my REXX days, although I shudder to think of going back..
twrkit 12y ago
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 12y ago
  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).

freyfogle 12y ago

a similar project: http://www.openbankproject.com http://www.openbankproject.com

mrweasel 12y ago

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 12y ago
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 12y ago
 ... 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_informa#comment-46 http://www.asktheeu.org/en/request/information_on_financial_... [2] http://www.swift.com/about_swift/shownews?param_dcr=news.data/en/swift_com/archived_news/61159_carl_reuterski_ld.xml http://www.swift.com/about_swift/shownews?param_dcr=news.dat... [3] https://en.wikipedia.org/wiki/UANI#Leadership https://en.wikipedia.org/wiki/UANI#Leadership

Roonerelli 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.
JoelJacobson 12y ago
You could with benefit send FIX messages over BankAPI, as it doesn't define the content of the messages transferred.

lorddoig 12y ago

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?

easytiger 12y ago
And what does it offer above ssh/ssl on their own?
mnem 12y ago
It appears to be from https://trustly.com/en/ https://trustly.com/en/ so perhaps they use it internally and are open sourcing it.
- lorddoig 12y ago
  I should have checked that before commenting, itchy trigger fingers I suppose. It makes a great deal more sense now.
tveita 12y ago
They call it "production grade quality", but I don't see a test suite.
- judk 12y ago
  Maybe it's production grade F
- JoelJacobson 12y ago
  There is a system test which tests all components together, see demo.sh and demo-bankapi.sh.
12y ago

infinii 12y ago

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

JoelJacobson 12y ago
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 12y ago
 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 12y ago
 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 12y ago

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

mtkd 12y ago

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 12y ago
This doesn't link to trustly.github.com though.
- corin_ 12y ago
  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

dqmdm2 12y ago

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

peteretep 12y ago

If it kills Connect:Direct, hooray!

zAy0LfpBZLC8mAC 12y ago

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?

runeks 12y ago

> 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 12y ago
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 12y ago
  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_part1_rev3_general.pdf 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/key-size.htm http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/k...
  - JoelJacobson 12y ago
    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)