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

31–40 of 87 posts

Re: BankAPI

#31

Post by chollida1 »

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

Re: BankAPI

#32

Post by pharaohgeek »

iamsalman wrote: post #4

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…

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.

Re: BankAPI

#33

Post by zrail »

wclax04 wrote: post #14
mrweasel wrote: post #13

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

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

SWIFT is generally reserved for international transfers. In the United States domestic bank transfers use ACH which involves FTPing fixed-width-column EDI files to and from the Federal Reserve every night. ZenPayroll had a really good series on how it all works a few months ago:

Part 1: http://engineering.zenpayroll.com/how-ach-works-a-developer-... (HN: https://news.ycombinator.com/item?id=7636066)

Part 2: http://engineering.zenpayroll.com/how-ach-works-a-developer-... (HN: https://news.ycombinator.com/item?id=7740967)

Part 3: http://engineering.zenpayroll.com/how-ach-works-a-developer-... (HN: https://news.ycombinator.com/item?id=8007838)

Re: BankAPI

#34

Post by techdebt5112 »

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…

this type of encrypted messaging is super common between banks and third parties. it's usually done in a similar manner to what is implemented here but in SFTP and every bank has it quirks/a different system for ACKing transmissions. a standard would be nice :)

Re: BankAPI

#35

Post by drivingmenuts »

jacquesm wrote: post #6
xedarius wrote: post #3

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.

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?

Re: BankAPI

#37

Post by drivingmenuts »

twrkit wrote: post #10
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…

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.

How's the pay for Fortran programmers?

Both Fortran and Cobol are capable, but unexciting, languages. I'd be OK working with either one if the pay was good and the employment guaranteed.

Re: BankAPI

#38

Post by spacefight »

ThomPete wrote: post #30
RobinUS2 wrote: post #2

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

Yes some of the largest Northern European banks. https://trustly.com/en/

I loooked at their pricing page on https://trustly.com/en/pricing/ - not a single price is there. Come on guys...

Re: BankAPI

#39

Post by drpancake »

spacefight wrote: post #38
ThomPete wrote: post #30

Earlier quoted context omitted.

Yes some of the largest Northern European banks. https://trustly.com/en/

I loooked at their pricing page on https://trustly.com/en/pricing/ - not a single price is there. Come on guys...

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.

Re: BankAPI

#40

Post by corin_ »

vertex-four wrote: post #25
mtkd wrote: post #23

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

This doesn't link to trustly.github.com though.

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
Post reply on HN