Good idea, but I've always been a bit skeptical it will get much traction. However, from FT via FT Alphaville on Friday:QuoteDeutsche Bank is seeking to convince rival investment banks to share markets and trading software in an effort collectively to lower costs for the financial industry, reports the FT. Sharing software would be an unusual step for investment banks, which have historically closely guarded their technology, much of which is still built in-house at great expense.Anybody knows of any actual on-the-ground steps towards this?

I think it's only a matter of time before it is done and successfully.The Chemical industry followed the same path a few years ago: major chemical companies used to develop in house system to simulate the results of their processes before starting to plan how to organise and build plants to produce the substances they needed. In a way they had their breed of quants who would spend their days writing system to translate the iteractions between molecules in systems of differential equations. Then as the margins started to narrow, they realised that it was silly to recreate similar methods along the industry, and they spinned off their "quant" units and funded collectively the creation of software companies to give them the same services. By each owning shares of the generated company they guaranteed the fact that the research was shared among the initial creators.Economically speaking this is also meaningful: it goes down to specialisation of labour. It doesn't make economical sense to have a bank investing and using its resources to create computer programs (that is not its core business) instead of "doing banking". It's better to have a bank that only concentrates on "banking" and software companies that concentrate on "software".I wonder if the creation of excellent packages like "QuantLib" and "OpenGamma" will make this step very easy...

Something similar happened in reservoir engineering. 30 years ago new FEM simulators were built. It was all novel. Now AFAIK you can buy these off-shelf.The oil and gas industry has been standardised. But it will take years to reach consensus on interfaces etc. It will also demand a 'paradigm shift' by develeopers. A good branch is Telecom. QuoteI wonder if the creation of excellent packages like "QuantLib" and "OpenGamma" will make this step very easy...The solution is not just software but Interoperability standards. I (unfortunately) don't see this happening any time soon.

Interesting! This development will increase systemic risks in two ways. Although it should reduce the risk that one bank loses $X billion on a software/modeling error, it increases the chance that ALL banks lose $X billion on a software/modeling error. Moreover, it may increase asset bubble systemic risks due to accelerated adoption of financial innovations by reducing the mean-time-to-one-trillion-dollars of NBT (next big thing) contracts.

QuoteOriginally posted by: bojanGood idea, but I've always been a bit skeptical it will get much traction. However, from FT via FT Alphaville on Friday:QuoteDeutsche Bank is seeking to convince rival investment banks to share markets and trading software in an effort collectively to lower costs for the financial industry, reports the FT. Sharing software would be an unusual step for investment banks, which have historically closely guarded their technology, much of which is still built in-house at great expense.Anybody knows of any actual on-the-ground steps towards this?The quite does not really specify which element of software. It can be argued that a lot has happened already: most banks use Fidessa for Cash Equity Trading, then there are a whole host of other products like Rolfe and Nolan, Sophis, Murex etc. The question for this forum is the analytics and here I think there are serious interoperability issues for products, and no bank will share how it builds a yield curve or measures risk as this should be what sets it apart from his competitors.

Quotethis should be what sets it apart from his competitors.I am glad you used the conditional form... I would like to know which bank does anything innovative at all. There are hundreds of "proprietary" hacks to SABR and other hundreds ways to improve the calibration of Heston, but apart from giving some minor pleasure to a few mathematicians, I don't think they really give a great advantage to a bank with respect to others.In the golden days pre-crisis it seemed easy to make money by increasing the leverage on capital. But now that it is clear that models don't reduce risk to the point that leverage can be increased at will, and regulators force banks to keep a lot more in reserves, I think that a bank can make more money borrowing and lending rather than structuring complex product based on flaky models.I listened to the speaches by a couple of CEOs recently and I think that this message is starting to reach that level and when it truly does, I am afraid the good days for us are over.

QuoteI listened to the speaches by a couple of CEOs recently and I think that this message is starting to reach that level and when it truly does, I am afraid the good days for us are over. In what sense, 'over'? Or are there new opportunities?

I think it depends what you class as innovative. it is unlikely anyone is running any new models out there at the moment that have not been published as I am not sure Op Risk/Vetting etc would be willing to take the risk if the model was rubbish. However how you construct a yield curve I would have thought if not innovative is pretty much down to the individual bank.

Let me add a very personal view on this and please don't treat this as an ad, but more as some views by someone that shares software for a living. Letting aside the vagueness of the original post, I think: I find it horrible by banks to do that initiative. They undermine free standards and hinder innovation, by building industry interest groups. Although one might say that harmonized and unified software platforms should pose a stimulation, they are often also an obstacle for many reasons. A) (Industry) committees represent the interest of their committee members. B) A dominant market position of one specific platform leads to the creation of an ecosystem around this platform, thus drying out smaller ecosystems. C) A concentration of software suppliers increases the Herfindahl index beyond the free market point, thus indicating to a monopoly or an oligopoly. D) While a standardization lowers market entry barriers for clients, it also increases the dependency of these clients on the standard platform provider. E) As a foreposter said, systemic risk increases due to a monoculture effect [compare farming and monoculture]. While I can see a need for reusing existing components instead of reinventing the wheel, I also see that these issues are already addressed in today's software ecosystem. Open source software projects come into mind. Platforms like QuantLib, R, Linux come into mind. While from an economical sense, it makes sense to strive for economies of scale on common functionalities which lie outside of corporations' core competencies, such a move sounds like a prestep to vertical integration. Clearly, functionality such as back-office functionality, reporting functionality, risk calculations are relatively standard and are candidates for being developed communally. But are banks the right place for developing something openly? Can we expect such a thing as an OpenSource library from banks? Is it not rather going to be a closed down effort, available to only a few? ----http://www.activequant.org

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnSomething similar happened in reservoir engineering. 30 years ago new FEM simulators were built. It was all novel. Now AFAIK you can buy these off-shelf.The oil and gas industry has been standardised. But it will take years to reach consensus on interfaces etc. It will also demand a 'paradigm shift' by develeopers. A good friend of mine is reservoir engineer at a large oil company, and even though the algorithms might be settled in principle, both the coding and the algorithms is always in developement. They e.g. hired the company where Zeta used to work (it's a small world) to rewrite the algoritms for GPU and do CPU optimalisation, and I think my friend himself introduced wavelet methods to create faster algorithms.I agree. I worked in the same lab (Rijswijk?) as well as the one in Amsterdam in 1989 onwards In contrast to 1989, the s/w is no longer big secret, state-of-art. It has become a kind of commodity. These days it's just fine-tuning as you say. And being done by non Western Europeans in the main..C++ is the standard, but I am not sure if it is a better solution than Fortran. C++ is just OK for maths IMO.

The oil industry has standardised in protocols and interfaces. Then it is up to each company and contractor to implemenet.IMO having open source libraries libraries is not on the critical path. Instead of yield curve s/w, better to define global interop standards.

I had a MSc and PhD in FEM and C++ knowledge and lots of VAX/VMS at the time where I was a contractor, so the project was new and did not go to contractors. How times change. I used FEM for other industry projects, before and after Rijskwijk.