Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An oral history of Bank Python

calpaterson.com

Post reply on HN
Print view View original

51–60 of 333 posts

Re: An oral history of Bank Python

#51

Post by simonh »

lozenge wrote: post #34
cstross wrote: post #11

This immediately sprang out at me: > Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out. I wonder how well this plays with the various open source software licenses?

Most licenses just require your users to have access to the source code. As all the users are bank employees, this is usually easily achieved. If the license is violated it's only by accidental oversight. Pretty much everything described is a Python library not a change in the Python interpreter so can be under a proprietary license. The spirit of open source is a different matter.

As I understand it from a legal point of view the user in this case is the bank, not individual employees running it on the bank's behalf, and the bank already has the code so it's a non-issue.

I know some people think this is contrary to the spirit of open source, but it isn't. One of the goals of open source is so that users can customise the code to their specific use case, with no obligation to share. That's all the banks are doing. They have the same rights as any other user.

Re: An oral history of Bank Python

#52

Post by pepoluan »

oxfordmale wrote: post #43

I worked for a hedge fund that build their own database on top of MongoDB. Data was serialised and stored as binary blobs. This bonkers implementation took away any advantage of using MongoDB. Unfortunately this system had a lot of political backing, and rather than addressing the short comings we were told to simply datasets to ensure they could be stored in this bespoke database. I suspect a lot of trading signals…

> I suspect a lot of trading signals were lost this way.

If you can prove & show evidence about this, I'm sure they will (grudgingly) accept the need to improve.

Financial institutions are mostly risk-averse, "if it works, don't fucking fiddle with it!" They need something that will impact the bottom line in an (almost) direct way.

I remember working with a financial institution back in 2010. I pushed for virtualization by presenting scenarios where the main servers are impacted, we have no warm backup servers, and calculate the impact to bottom line using known MTTR (Mean Time To Recovery) values of similar scenarios (gathered from incidents all over the world).

Took several back-and-forth meetings with the BoD, but in the end they accepted the need to improve and allocated the funding + greenlight the project.

(That was also back in the day when Microsoft had just released Hyper-V, and when we asked Microsoft to join in the project, I talked to their head engineer, and they respectfully declined because "their internal testing shows that Hyper-V, at the moment, is unable to fulfill the required parameters". Ended up with XenServer.)

Re: An oral history of Bank Python

#53

Post by urban_winter »

BAML Quartz was conceived by a bunch of front-office quants who had not the first idea about the software needs of a big bank beyond the front office. There was an arrogant assumption that front office software is obviously the most complicated/difficult variety of software within a bank and therefore any system designed with front office requirements at the forefront would, of course, be perfect for universal use.

This assumption was challenged at the time by various groups - I was closest to the Equities Operations software team (although not part of it) who absolutely dug in their heels and refused to use Quartz. The assumption was explosively invalidated when people started implementing in Quartz applications that fell under Sarbanes/Oxley regulations and Quartz picked up a severity 1 audit finding - because Quartz was explicitly designed for "Hyper Agility" (literal quote from the quartz docs) - and anyone-can-change-anything-at-any-time does not make for applications that the regulators trust.

There was an interesting trajectory of Python hiring during my time at BAML. I joined just as Quartz was getting started and we managed to easily hire tens of python devs in London because it was easy to sell the fact that BAML was making a strategic investment in Python and therefore their (at the time relatively uncommon) skills would be highly valued. But as Quartz matured, Python developers generally came to dislike it (for reasons see original article) and it became hard to retain the best ones. And after a while Python 2.x became a massive embarrassment and, as Python became a more common skill in the marketplace, it became harder to hire good developers into BAML.

Re: An oral history of Bank Python

#54

Post by globular-toast »

cstross wrote: post #11

This immediately sprang out at me: > Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out. I wonder how well this plays with the various open source software licenses?

As others have mentioned, it's fine, even with GPL, as the licences only really kick in when they try to distribute the software. They are only really hurting themselves. When starting a private fork you force yourself to maintain it alone. That means either letting it rot (ie. it becomes insecure and obsolete with no new libraries supporting it) or keeping up with the mainstream yourself. Either way it's a lot of work that wouldn't be necessary if they upstreamed their changes. Maybe one day they'll get the message. You'd think that long-term investors would understand this concept better.

Re: An oral history of Bank Python

#56

Post by simonh »

urban_winter wrote: post #53

BAML Quartz was conceived by a bunch of front-office quants who had not the first idea about the software needs of a big bank beyond the front office. There was an arrogant assumption that front office software is obviously the most complicated/difficult variety of software within a bank and therefore any system designed with front office requirements at the forefront would, of course, be perfect for universal use. T…

I was at BAML when the sev 1 audit finding happened. My view was from an application support team in Risk. For us Quartz was fantastic, and it had a pretty decent permissions system. The problem is there were two miss-aligned goals.

On the one hand the goal was to build a single enterprise scale system with a holistic view of the bank's data to do rapid ad-hoc position evaluations and meet new needs rapidly.

On the other hand, access to all that data and all the code is clearly a security concern. By the time I left the sev 1 finding was well on the way to being mitigated, but for example it meant that instead of handing out quartz developer accounts and IDE access like candy it had to be restricted to technology personnel only.

Re: An oral history of Bank Python

#57

Post by stevesimmons »

seanhunter wrote: post #21

I was the person who first deployed Python at Goldman Sachs. At the time it was an "unapproved technology" but the partner in charge of my division called me and said (This is literally word for word because partners didn't call me every day so I remember) Err....hi Sean, It's Armen. Uhh.... So I heard you like python.... well if someone was to uhh.... install python on the train... they probably wouldn't be fired. O…

I worked on Athena at JPMorgan for 8 years, and loved it.

Seeing Python at the core of trading, risk and post-trade processing for Commodities, FX, Credit etc was such a great developer experience.

By the time I left JPM, there were 4500 devs globally making 20k commits weekly into the Athena codebase. (I did a PyData presentation on this [1] for more details).

The one downside was the delayed transition from Py2.7 to 3; I left just as that was getting underway.

[1] https://www.youtube.com/watch?v=ZYD9yyMh9Hk The

Re: An oral history of Bank Python

#58

Post by carnitine »

Always funny to see the objections of new hires without finance experience to the use of floating point for pricing. It’s more related to the inherent inaccuracy of any pricing model though, rather than clients not caring about pennies.

Re: An oral history of Bank Python

#59

Post by misja111 »

rich_sasha wrote: post #24
lmm wrote: post #19

I'm seeing a lot of people speculating about which bank this might be; I think the point is that it's all of them. I could loosely describe a previous job as implementing Morgan Stanley's Walpole and integrating more source code management into Minerva (even though that system wasn't actually Python-based). Having a global view on everything is large banks' value-add, it's why they haven't been outcompeted by their m…

I think it’s mostly true. The complaint with this kind of “industrial global Python code base”, be it at banks or elsewhere, is that often they are hastily cobbled together and depend on extreme user care to not flop over all the time. I guess banks are the archetypal places that care only about feature creation and not about maintenance or technical debt. When something does break in the end, someone senior just sho…

> I guess banks are the archetypal places that care only about feature creation and not about maintenance or technical debt.

It depends which department you are in, but in general: absolutely not. Actually the reverse is true. Banks have huge risks to manage: just imagine for instance what damage a hack of their account system could cause. Or a crash of their payment system. Therefore it is of the utmost importance that systems are stable and bug free. In most departments, feature development is only in second place: stability and reliability have priority one.

This concern is so important that it is not just left to the responsibility of the banks themselves: for many systems, banks have to comply with external standards and are audited for that by external agencies.

Re: An oral history of Bank Python

#60

Post by tecleandor »

transitory_pce wrote: post #37

Title should be ".. of investment bank python", trading and risk has little in common with a retail digital bank like say N26. The problem with these projects is that the folks leading them have never built a real trading system in entire their lives (the ones who have been there for many years worked with end-of-day batch systems) and there is a layer of useless and incompetent "business analysts" who hide behind th…

When you say "The problem with these banks..." you mean the ones like N26 (not investment banks)? (Seems like coffee hasn't kicked in for me yet)
Post reply on HN