Hacker News Reader

Comment by osullivj | Hacker News Reader

I started working in financial tech in 97, and I've seen a number of "one model to rule them all" efforts come and go since. Back in the late 90s I saw consultants touting Java coded UML models as the way for banks to build the definitive object model of their trading operations. In the early 2000s I worked on JP Morgan's Kapital, an early 90s Smalltalk risk management system using the Gemstone DB. That was supposed to be the last word in derivatives abstraction. And more recently I spent some time working on JP's Athena project, a Python NoSQL system with an implicitly functional graph programming system that enables Python code to behave like spreadsheets. I suspect the ability of traders to invent products, and more recently regulators to invent rules, will always outstrip the ability of coders to invent clean abstractions that will factor the financial domain neatly.

View on HN

(exJPM here) This is one of the cleanest, simplest descriptions of Kapital and Athena I heard in a while :)

one thing to also keep in mind is no matter the sophistication of models, there is always gonna be some person in front/middle/back office somewhere, running a critical process on excel for 3 years.

I'm an in house dev for a financial company - if you really want to "stress test" a financial institution turn off Excel for a week and you'll find all the things you never realised people were doing. I've been bitten far too frequently to ever believe what the product owners says a process is, there's always a spreadsheet somewhere used to work around the existing system...

I'd like to affirm your view that work arounds are a fact of life in finance, and frankly, other white-collar enterprises as well.

While they're stashed relatively deep in my memory banks (mostly for the purpose of forgetting), I do have dozens of experiences 'touching up' PDFs, reverse engineering or cloning things from PDFs of PowerPoint presentations, or otherwise using whatever digital hammer and chisel would get the job done. Screenshot > Paint > Fix > PDF, boom!

Love that. I'm working in group benefits insurance now and spreadsheets are how everyone communicates. The software is just there to hold the data in between spreadsheet imports and exports.

Are the spreadsheets doing real number crunching? Do they use XLLs and VBA, or just worksheet functions?

Very often yes, to a scary degree. The amount of data normalization, adjustments, aggregation, analysis, etc that happens in some poorly documented and ill maintained macro is mind-boggling (there is a term for it - a model/process being "offline", i.e. not properly source-controlled or auditable).

The real reason is because Excel is still by far the simplest, quickest way to get something done fast when the deadlines are always "yesterday!".

I was in finance as well as trading risk management at one of the largest physical commodities trading houses in the world ($100+ billion revenue) and orders, positions, PNL, inventory, inventory movements, market research and analysis, and general business reports... yes, very expensive systems backing them... and they had to be done on Excel manually and synced daily to make sure if the main systems (absurdly complex) got out of sync, either one could be repaired as a failsafe.

There is one (at least) of these systems live based on the original paper by Simon Peyton Jones in a dialect of Haskell.

JPM/BAML/GS have fallen down due in large part to their choice of language in my view. A graph database written in a hurry in C++ then glued together with tens of millions of lines of hacked up python is not the way to build a bank wide platform in my book!

What is the paper's title? I'd like to understand the theory behind this approach.

Probably this one: http://research.microsoft.com/en-us/um/people/simonpj/Papers... ("Composing contracts: an adventure in financial engineering"). If you have the book called "The fun of programming" (abound functional programming), you have an updated version of that paper; the chapter is called "How to write a financial contract".

[EDITED to add: This is also the first link in the OP.]

One of these banks is definitively not like the others.

And yet GS was the progenator of both Athena and Quartz....

More specifically, the GS alumni who lead the Athena and Quartz builds at JP and BAML are now commercialising that approach as wsq.io

Correct. I hope they learned some of the lessons from both!

Same here, only I started some time earlier and have implemented the central trading system side of all these instruments. I agree, the basic contracts and simple combinations are the simplest part.

But are not the basic contracts where all the volume is - is the opportunity for new banks to come in and provide volume on a new cheap stack? Existing banks seen usually add enormous implementation costs trying to solve the last 20% (reasonably as that's where profit tends to be) but it makes implementing the first 80% almost impossible

I see this elsewhere too - solving business problems with software tools not with business tools.

Forgive me, but I will be stealing that last sentence ... It's great.

Reply on news.ycombinator.com