Friday funnies

Friday funny story

Working with financial markets means often stress and pressure to deliver under a short timeframe.

So trying to push some of the stories I’ve lived (hopefully funny for you too) to lighten the mood just before the weekend.

This story happened while working on a project. The character here is a brilliant person, very smart and quick to understand but even the best sometimes have their weaknesses.

So I get a call from that person asking me what happens when the trade number ID gets above 10,000 and given that the size of the field is 10 digits. So my first answer is 10,001 but I suspected that there was some confusion between 10 digits and 10 times 1,000. Anyway the person hangs up and 20 minutes later I get a call that the project is threatened.

Had to get there and explain everything even if I felt bad that a simple misthinking snowballed into something bigger. Anyway, better to laugh about it now!

Tips

Database traces

Database tracing is very handy when you’re trying to grasp what is causing an error and you suspect something wrong in the configuration (an incorrectly setup security, market data, etc…) or you’re looking to build an SQL query and need to have a bit of a better understanding of the data model (note that I do not encourage you to use SQL, reporting and dynamic tables should be your first stop but sometimes it is not enough).

In Murex there are couple of database traces and some are more useful than others.

The first one I used is the one coming up through the GUI. Every request pops on the screen and by pressing escape gets executed. It’s simple to use, simple to turn on and don’t need to retrieve the file from the application server. Sadly, it sometimes causes crashes due to the popup windows interfering with the application or sometimes you simply have too many requests for it to be useful.
To turn it on, you need to go to Help-Monitor-DBX Info-Request . You can then enter criteria to filter the requests: From the action (update, delete, insert, select) to a string search (e.g. TRN_HDR or BOND001).
When I began in the Murex world, I loved that tool as it helped me put together the pieces of the puzzle.

The second one is to activate the traces dumped into a log file. To do so, go to Help-Monitor-DBX Info-RDB Statistics. You can choose what level of debugging you need. The basic one is good enough if you need to look at the queries executed. The full verbose (apart from the plan) one is necessary if you’re trying to track missing DB Indices or need to understand which requests are costing too much time. That trace will by default dump files into logs/mxsession/mx but the default path can be modified within the launcher.
One can also turn on that tracing with a slash command: /RDXSTATISTICS:<prefix>:<trace level>

You might end up using the information given from the traces for:

– Building a report

– Building a RQWHERE filter

– Narrowing down an issue

– Building a SQL procedure (useful when upgrading/reconciliation but always check with Murex if it’s all good)

DB traces are not the silver bullet and sometimes won’t give you the information you’re after. Also in case of investigating a crash, keep in mind that the last request might not be the one responsible for the crash and you might need to go back up in the logs to find the root cause.

 

If you have questions, funny stories or feel like it, please comment below!

News

Volatility news

I was starting typing a post about volatility (you’ve understood that it will come later) but getting some material I got into quite a few articles about the expected rise of volatility for 2015.

For instance CNBC  or here .

It’s important in our line of work to keep updated about these articles as they’re often going to translate into concerns or demands from customers. For instance, the interest rates going down led to requests for shifted lognormal volatilities and normal volatilities.

I’ll try to keep posting whenever I see some articles of interest and feel free to do so too!

Info

Funding curves

In the extension of the previous post, I’ll cover a bit the funding curves: what it means and how they’re being used.

  1. What are the funding curves?

A funding curve crystallizes the  funding spreads over the market rates for the bank. Usually you will find that these spreads are over the O/N rate and the funding curve is often in USD.

That curve represents the cost to the bank to fund their positions. When it needs to be expressed in different currencies the current approach is to ratio discount factors: Df(XXX funding curve)/Df(USD funding curve)=Df(XXX/USD basis curve)/Df(USD OIS curve). The assumption behind is that swap points are a constant.  So you end up with the discount factor you’re after (Df(XXX funding curve) as Df(XXX/USD basis curve)*Df(USD funding curve)/Df(USD OIS curve).

2.  How to set them up?

In Murex, this can be setup using the Automatic CSA curve setting. You’ll need to define a CSA category (such as No collateral) and attach the proper curve assignment to USD (assuming you’re using USD for funding).

3.  When are they used?

Trades can be collateralized or not. To be collateralized, they need to be covered by an agreement with your counterpart and in that case, any large market value for that transaction will trigger a margin call and thus limit the risk for both sides.
When the trades are not collateralized, this is when you want to use the funding curves as the bank is much more exposed and the returns expected are higher.

In terms of pricing, this also means that when trading with a non collateralized counterparty, the prices will be worse given the increased rates.

4.  Anything else? Risk management maybe?

This is where the funding desk comes into the picture. The role of that desk is to determine the funding spreads but also to manage the risk coming from these curves. For traders, they will also look at their portfolios as if all trades were fully collateralized BUT any trade with a counterparty with no agreement will effectively use the funding desk as an intermediary : the funding desk trades the same trade back to back, with the counterpart using the funding curves and with the trading desk using normal curves (OIS or basis curves).

In a nutshell, that’s what funding curves are about. As always, questions or comments are more than welcome!

Info

Rate curves

Today’s post is about rate curves, what they are, their purposes and where things are at the moment (Of writing this post)

  • What’s a rate curve?

The point of a rate curve is to produce discount factors (or discounting rates) in order to discount cash flows, estimate rates or capitalize a cash flow. In school, you tend to consider that there is an unique flat rate for all your discounting needs but in fact the rate is not constant over time and tend (it’s not a guarantee at all) to increase over time as your risk increases.

  • What’s inside a rate curve?

The main problem is that you need to find rates which are the best representation of where the risk free rates are sitting. So you’ll want to use the most liquid interbank instruments. For a standard curve, you’re usually looking at deposits on the short term, rate futures on the mid term and swaps on the longer term.

  • Is there more than one curve?

Sadly, yes. When I started people were using only one curve making risk management a hell lot easier. Then the cross currency basis curves appear. The expectation was that risk  is different for transactions which used more than a currency (FX deals and currency swaps for instance). So one would build a curve with liquid cross currency deals (today’s trend is swap points up to 1y, 18m and currency swaps on the longer run).
But it did not end there! Afterwards estimation curves were introduced as forecasting a 3m rate, 6m rate and 1m rate on the same curve was not returning correct results. Depending on the curve, the instruments are different but usually deposit for the first pillar as it also anchors properly the fixing rate for the day once published, futures or FRAs if available/liquid and basis swaps (also when available/liquid).
Finally, the curve that is maybe the most popular now: Overnight curve (Also called OIS Curve (for Overnight Index Swap). It is used for forecasting the overnight rate but also discounting many transactions (normally all collateralized ones, but I’ll detail that in another post). OIS curve is built using a depo for the O/N pillar and then either futures when available/liquid and OIS for the longer run.

While all these curves return a price which tends to be much closer to the market, they also make risk management a lot more complex especially as curves are related. So non rates traders are forced into this world and need to hedge their basis risk where before they were just looking at a single IR risk figure per currency.

Feel free to discuss further in the comments below or the forum, but it is a vast subject and worth actually multiple posts rather than just one.

Info

Bank organization

This post is not really for you veterans out there but more for more junior readers for which there is a bit of mystery about how a bank works.

If we focus solely on the financial markets part of the bank, you have 4 big categories:

Front office: This team encompasses the traders, the quants (depending on how a bank is organized, you sometimes have FO quants effectively sitting with the traders and pure quants), sales, treasury and FO management.
Processing: This massive team (sometimes referred to as Back office) processes confirmations, accounting, payments, securities and cash nostros, …
Risk: They ensure that the risk held by Front Office is actually within limits and their job is to ensure that the bank is not too exposed. You will find here risk controllers.
IT: The role of IT is to ensure that all works as expected. They are also in charge of upgrades/migrations (with the help of the teams above).

Of course, you have some roles which actually sit in between 2 or 3 categories and within each categories you have roles which are very different. But the idea here is to draw attention that there are different needs and drivers between teams.

Murex consultants normally act as second level of support and are most often contacted by people from the IT category. It often happens that they find themselves on the front line especially on more complex or urgent issues.

At some later stage, I’ll try to detail a bit more within the different groups but if you’re impatient or got some questions, feel free to ask!

Tips

Debugging crashes

1 Comment

Alright, this post will be very much focused on how to debug issues and will be low level.

Murex does crash and number of times, working for Murex we did not get all the information we needed to pinpoint precisely the problem.

The system crashes… what to do?

The first thing is to gather information from the user encountering the crash and understand what was the user doing, if it happened regularly, etc… One important thing to check, if the crash is recent: was anything changed recently (change of configuration or setting for example).

The second step is to reproduce the crash on your side (hopefully without the user). If the crash is too random or cannot be reproduced at will, the best is then to gather the core files and share them with Murex to obtain more information as to what the session was doing at the time.

Assuming the crash can be reproduced, the next step is to narrow it down. This step will actually speed greatly the turnaround from Murex side on the problem. And it might also lead to a workaround to the crash. Depending as to where the crash is happening, there could be multiple way of proceeding. I’ll cover the most common case: crash happening while loading multiple transactions.

If you’re lucky, the transaction scan watching might give you the answer. Transaction scan watching basically logs in when a transaction is opened for valuation and then logs it out. So each transaction should appear an even number of times. If one does appear an odd amount of time (and it’s the last one on the list) you might then have a winner. To confirm that the transaction is indeed the culprit, just try your process (accounting entries generation, simulation) on that single trade and see if the crash occurs.

To use transaction scan watching, go to help-monitor, SPB Information and choose transaction scan watching (Zap). This will delete the existing log (transaction scan watching is only used for debugging, you do not endanger anything by zapping it out, except of course if someone else is doing debugging at the same time!). Then choose activate and run your process again. Once it crashes, with a new session choose Transaction scan watching (Display) to check the log.

If the transaction scan watching fails to focus on a single trade, it will give you trades which have already been processed and might also give you a trend: all IRS have passed, it failed while doing loans. Be careful with this info as the way of scanning transactions is not always clear.
Without the transaction scan watching, to narrow it down, you then need to break it down by portfolios or deal type (usually the knowledge of what was changed recently helps as you can focus on what you suspect being wrong first). Don’t hesitate to use filters on trades inserted today or which had events performed on them during the day.

Once you have the trade, check it out (check also the static data and market data it uses) to understand where is the issue coming from. If you can fix it, it’s a win .
If you can’t, you can then test that the issue occurs with a new trade for which you picked the same pattern. And in that case, congrats you’ve found the bug and can raise it as such.

 

Info, Jobs

Scoring a job with Murex

In the continuation of the previous post, here are details as to how the interview process works and what is expected of you.

The level required by candidates is actually very high, this ensures people who can learn quickly but also it builds a company spirit where you are surrounded by very good people. This is very motivating.

For graduates (or non senior positions), one of the first things that happens during the recruitment is a knowledge test. Depending on the type of job you’re applying for, the test might vary. Without detailing what the tests can be about, the idea is to test what you should know (maths, financial questions if you studied finance, programming if applicable, etc…) but also how do you think and if you have the good reflexes when faced with a problem.

So for more junior people, revise what you have studied and also try to understand what Murex is about (this website and Murex website will be good sources of information).

If you manage to get a job, you will receive trainings from Murex about basics (what’s a rate curve, what are the different type of options, what are accounting entries, etc…) the idea is to ensure that even if you are not working in a particular domain, you have a basic knowledge as to what it is. The trainings then move to specificities of Murex and how the software works, the internal processes, etc…

While the training takes 6 weeks to 2 months, Murex tends to consider that the investment in someone starts to pay off after 18 months, once you build confidence and knowledge. There will be lots of things for you to do prior to that but you’ll be well assisted to insure you learn as quickly as possible.

As 18 months is a significant amount of time, it is important for Murex to recruit the right people, hence the focus put on the recruitment process.

For more senior positions, this is of course on an ad hoc basis given how well your skills are transferable.

More questions, feel free to comment or go to the forums and I’ll try to answer them

Info, Jobs

Murex teams

Murex people are split into many different teams and sometimes it is not obvious which team does what. Let me detail the different teams here:

– Dev teams. This is the team customers will never talk with. Their jobs is of course to develop new features but also correct bugs and other issues. Most of the development is done from Paris.

– PES Teams (Product Evolution Services). These teams are the main interfaces between business and developers, they’re split by asset class or activity (processing for instance). Their job is to build the development roadmap with developers, write specs, test new functionalities, present roadmaps, assist other teams with asset specific questions. They’re often on the front line for presenting the software as they have a strong understanding of the business needs and the software. Location wise, they’re mostly based in Paris along with developers.

– CES Teams (Customer Evolution Services). These teams are in charge of following customers. They’re usually the first point of contact for customers and will follow internally on what a customer needs. Outside Paris, most consultants are classified as CES as they’re all customer facing.

– PAC team (Performance and Architecture). They have multiple missions: work with the dev team to agree on the architecture to be adopted by the software: services, modules, technology used,… but also monitoring and improving the performance of the software. For example, ensuring that the software could cope with a large volume of transactions without slowing down (FX cash business) is their work. They’re also tasked with assisting customers in choosing the right hardware and producing performance tests.

– Operate. This team works 24×6 (if not 24×7) and is a second line of support for Murex teams. They have a large knowledge of the application and assist the other teams in many ways (building a new environment, tracking a crash, etc…)

– QA. The team is mostly based in Beirut and crunches through all the reports generated everyday tracking any regressions or undocumented change.

– Release management. Their job is to ensure that the software patches and versions are released on time.

– Bizdev. This one encompasses:  pure bizdev people on the lookout for new opportunities, following on prospects and account managers who are tasked with building a strong relationship with the customers.

– MTEK team. Murex documentation team, ensuring that all documents are of high standards, properly formatted and of course available to all customers.

– CDS (Client Delivery Services). This team follows projects and provide everything project wise from mandays to achieve tasks to project management and solution architect.

I have likely omitted some other teams (and I apologize to them in advance) but these are the main ones and which are mostly specific to Murex. I suspect that everyone knows that Murex has a Marketing, Accounting and legal departments!