Tag Archives: organization

Info

Market data interface – How to get them in!

3 Comments

In this post, I won’t cover the different types of market data you can have in the system. Think about one and Murex will have it already either natively or through the user definable market data. Today, we’ll focus on Market data interface and the different means to load that data in!

Market data interface – The UIM

UIM does not stand for Ultimate Iron Man but Universal Input Method aka manual input (sounds less fancy that way). While many people would look down at the manual input, it is actually often relevant. If you’re considering a very small amount of data, that requires sanitization and is limited to a few times through the day, manual input is a good solution. Especially when you can set it up so all you need to do is copy/paste. I don’t say you should always push back on interfaces (well, actually I do) but you should actually consider it in many cases.

Market data interface – MDCS

Let’s dive into more acronyms (nothing to do with Marvel DC comics Series), MDCS stands for Market Data Contribution Service. This interface is mostly used for realtime market data feed.

How does it work? You have a service: RTBS (I’m running out of Superheroes jokes (already!)), export, direct publication which published data to a memory : MDCS (also called cache for aficionados). You can query the content of the cache either through XML request scripts or via the monitor.

The data is structured into multiple pages, with multiple nicknames.

From there, you can push that data either to database via a processing script. You can retrieve it via XML requests (note to all tinkerers: do not use that service as a way of distributing market data to all bank systems, you’ve been forewarned!) or have Murex sessions accessing it via activity feeders. Activity feeders give you the opportunity of choosing which type, page and nickname of market data can the session access.

So as you should have understood now: MDCS is the realtime service in Murex. And it is better used that way. For end of day, you should rather stick with the one after: MDRS.

In case of issue with realtime, you first need to check via monit or xml request scripts if the market data in the cache is properly updated. Which one to use should not even be a question as monit is easy and user friendly to use. If you can’t get the monit password, let the one with the password handle the issue!

If the data in the cache is properly updated. Your issue comes then from the activity feeders. You can restart them if required after trying with a new session (you should get an error message if the session can’t connect to them). If there is no error message, no realtime, check that you have indeed assigned an activity feeder to your session.

That’s the basic debugging of MDCS: check the cache, check the activity feeders and check the user settings.

Market data interface – MDRS

Market Data Repository Service. First of all, some good news! XML request scripts are almost identical to MDCS ones.

MDRS lets you retrieve and update the database directly via XML request scripts. It is effectively more efficient than MDCS-Processing script as you do everything in one go without having a stopover in the cache.

MDRS is actually pretty robust and never had too many problems with it especially if you read properly the documentation AND put the right tags in the right order. The usual trick with MDRS is to first query some market data to get the structure of the XML. And then add your Update command and modify the values as desired.

Again, Murex role is not to be the Market data repository for the whole bank. Murex primary role is to provide pricing, risk, processing services not centralize the bank market data.

Debugging MDRS is usually quite simple as you get an answer file and a log file whenever you kick in the XML script. Just fix as appropriate and you’ll be good to go!

 

That’s the 3 means of getting data in Murex, note that the services are always improved to cater for newer type of market data and especially when you’re working on new type of market data, you need to ensure that MDRS/MDCS properly support it. Otherwise, the UIM will always work!

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

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!

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!