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

41–50 of 87 posts

Re: BankAPI

#41

Post by lotsofcows »

chollida1 wrote: post #31
Roonerelli wrote: post #15

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

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

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

Re: BankAPI

#42

Post by jacquesm »

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?

> 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

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

Re: BankAPI

#43

Post by JoelJacobson »

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

Re: BankAPI

#44

Post by jacquesm »

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…

Before SWIFT moved to SwiftNet they used X.25, before that they used telex. Of course there was plenty of overlap during the transition, as far as I know X.25 for financial institutions is now all but dead, maybe there are still some ATMs connected to ISDN lines (X.25 packets can be sent via either one of the 'B' channels up to 64 kbps or via the 'D' channel at 16 kbps) but those are not part of SWIFT anyway but of a banks local IT infrastructure.

Re: BankAPI

#45

Post by ceejayoz »

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?

> How stupid do you have to be to trust core financial information to public communication methods?

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.

Re: BankAPI

#46

Post by minimax »

lotsofcows wrote: post #41
chollida1 wrote: post #31

Earlier quoted context omitted.

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

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

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.

Re: BankAPI

#47

Post by JackFr »

Ecio78 wrote: post #22
twrkit wrote: post #10

Earlier quoted context omitted.

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.

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

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.

Re: BankAPI

#48

Post by JoelJacobson »

infinii wrote: post #17

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

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)

Re: BankAPI

#49

Post by JoelJacobson »

ThePhysicist wrote: post #8

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

Author here.

Interesting thoughts, I agree most banks won't change because they don't even think they have a problem. Although there are a few modern banks who actually do use Linux, PostgreSQL and modern programming languages (not COBOL). :-)

I've addressed many of your thoughts in this text: https://github.com/trustly/bankapi/blob/master/doc/rationale...

I hope you will find it interesting.

Re: BankAPI

#50

Post by christiangenco »

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

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

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/

Post reply on HN