After writing 6 long posts on my experiences in EGB IT, I realised I still missed out many points. Here they are in no particular order.

• Squawkboxes are the most noisy thing on a trading floor. They are an old fashioned cross between a phone and intercom. They have a microphone, a speaker and a large set of quick-dial buttons to other squawkboxes in the same firm. They can also work as phones. When one of the buttons is pressed anything spoken into the microphone automatically comes out of the targeted squawkbox - no chance to screen or block the message. Traders love them for talking to support and salespeople - normally in a loud voice. I refused to have one on my desk once (I dismantled it and put it in my drawer). It is just too distracting to have traders contact you whenever they feel like it.

• Banks are full of compliance training. Each year front office staff have to do courses on diversity, money laundering, privacy, ethics and occasionally other topics. The courses consist of simple online training followed by an even simpler multi-choice test. If you fail the test, you just take it again immediately - most of the questions are the same. Rarely does anyone fail more than twice, especially since the content is the same each year. They are generally derided by all who have to do it, passing requires little more than remembering: stealing is wrong; you should be nice to everyone; you shouldn't talk about client details; and, talk to compliance people if you are not sure about something.

• The FSA also requires front-office staff to take two continuous weeks away from contact with the office. This is to help prevent fraud. The idea being that most frauds would be detected if the perpetrator is not around to keep it hidden. At three of the four banks I have worked this applied to front office IT people too. It's a good idea I think.

• Chinese walls (how did that term get past the diversity training?) abound in banks. That is where two parts of a bank should not talk to eachother for ethical reasons. For example, staff negotiating a potential takeover shouldn't talk to people who could trade on that information. Often these Chinese walls are manifested physically with walls and restricted access doors. At one bank a chest high row of filling cabinets was used. I sat within sight of this "wall" and often saw traders having a chat with the people on the other side. I'm sure no restricted information was ever mentioned.

• There is a concept in trading called "fatfinger", it is where someone enters data incorrectly, for instance buying 100 units of an instrument rather than 10. This happens often. Checking for this kind of activity is one of the reasons every keypress in a trading GUI is recorded.

• Phone calls are recorded in banks, as I write this a trader a few desks down is complaining a client just asked him to do something slightly dodgy on a "taped line".

• Slightly dodgy things happen all the time. The technology based ones that I see are accidental and tend to lose money. For instance, a bug in a trading system could result in actions that may constitute minor market manipulation - but such a situation would also most likely result in a loss for the bank, so no-one seems too concerned. Occasionally there are much bigger issues. The famous Dr Evil trade by Citigroup in 2004 was blatant market manipulation of EGB futures. Although many people around at the time suggest the fines levied were smaller than the profit made.

• One bank I worked at boasted that during the Dr Evil trade they didn't lose as much as other banks due to their defensive systems. Most EGB desks have various protections against putting out bad prices on the executable D2D markets. If the futures prices move too much all the quotes are pulled. If their quotes are lifted a couple of times in a few seconds all quotes are pulled (or perhaps all for a particular country). It is also common the have the spreads widen under various market conditions. Each bank has different set and they tend to change regularly.

• The traders also have a button on GUI to turn off all quotes. It is often called the "Panic" button, although the proper name is "Bank Off" (taking the bank off the market).

• The bank is normally off in the lead up to big announcements. I have never been aware of quotes being turned on over the non-farm payroll announcement. At one bank the traders were very impressed by recent changes to the pricing system and decided to try keeping quotes on through the number. We all went to watch and slowly saw liquidity dry up as the announcement approached. With just seconds to go we were the only ones left in the market and the traders decided it wasn't work the risk and hit the panic button. Commentators always talk about modern banking providing liquidity even at times of stress. My experience has been that at even times of relatively minor stress no one wants to quote, or they quote with huge spreads.

• To trade an order is sent to the market. This can be of two types: Fill-and-Kill (FAK), also known as Immediate-or-Cancel (IOC), where either the order is matched immediately (creating a trade) or it is discarded; and Fill-and-Store (FAS), also known as Good-to-Date (GTD), where if the order is not matched it hangs around for a set period of time during which it could be matched. Thus with FAK order a trade is done straight away or not at all, but under FAS the trade could occur some time after the order has been sent. A trade can be complete fill or partial fill (some markets also have zero fill - which is the same as no trade at all). Complete means that all the quantity requested has been filled, while partial means that not all the volume has been filled. For instance if an order is sent for $1M and only $500K is done, then that is a partial fill. One order can result in multiple trades. For instance if you put out an order for $10M and it may be filled by two trades of $5M against different counterparties. There are also iceberg orders on some markets. Icebergs are where the order quantity shown to the other market participants is less than the true order quantity (ie. some of it is hidden). This means that you can put on an iceberg order for $10M with a display of $5M. Other banks will see $5M and when that is filled the other $5M will be automatically available to be filled too.

• There are various interpolation algorithms for determining rates between points on a yield curve: cubic, splines, Gaussian. However, most places just seem to use linear (at least until recently) - that is just a straight line between points. Not particularly accurate, but good enough. Remember that market quotes are to 2 or 3 decimal places, so having your prices accurate to 7 decimal places is unnecessary and probably resulting in slow quotes.

• There is a double use of the term covered. A covered bond is like an asset backed bond (I'm not sure the exact difference). A covered auction is one where all the bonds on offer have been sold and the underwriter does need to buy any themselves.

• A typical trader at the places I have worked would have 6-8 screens. At least one would be showing pricing, one for positions risk, one for BBG and one for communication (Outlook, Bloomberg mail and/or some kind of instant messenger). Most traders would have a Bloomberg keyboard - used for its quick keys. There was always lots of Excel. They usually had 2 or 3 computers to support the large number of screens and heavy load from constant network updates. If the traders had a calculator it would always be the same HP model - easy to spot as it is wider than it is tall.

So after nearly 7 years on EGB technology teams I have moved on. Not out of banking (at least not yet), but when the opportunity came to try a different business area I jumped. This is despite being able to earn more money if I stayed in my EGB niche. There are two related reasons for leaving: the industry and technology are both changing to the detriment of developers.

When I started in 2005, EGB trading was already on an upswing that lasted through 2009. I'm not sure when this upwards trajectory began, but the people around me considered it normal. Business was good throughout the mortgage and banking crisis of 2008. When times are good and the desks are making good money some of it is reinvested into technology. There was a lot of optimism and this translated into banks wanting the fastest and smartest trading platform. We got to rewrite systems. Increasingly business was relying on technology - it was becoming trade-by-wire. It seemed that there was much further to go. Algorithmic trading is big in equities, why couldn't it be big in fixed income too. There was huge potential for writing interesting code.

This environment no longer exists. It was only when the European debt crisis began to bite in 2011 that things trended downwards, but then they went down fast. There is a great deal less ambition among the fixed income desks. Most traders seem happy just to not be losing money - something many are not achieving. Some banks are shutting down their bonds desks. As a natural consequence there is less to spend on technology and little desire to do more than maintenance. Flow volume is king, and as far as technology development is concerned, that is not hard. Thus less developers are required and the work is less interesting.

Combined with this is the creeping commoditisation of bonds technology. When I started Ion provided mainly gateways, little tools and their message bus. Over time they have climbed up the product stack. Now they also sell pricing engines, autoquoters, autohedgers, risk engines, position servers - nearly everything a bank needs to trade cash bonds. The quality is fine too. Their applications won't do everything a desk requires, but it will do most of it and the desk's technology team can add the remainder quickly. Not all banks will use vendor systems (many don't like Ion or see advantage in bespoke systems), but enough will to affect the market for EGB technologists.

Thus, once again, less developers are required and the work is less interesting. I don't see the situation changing until the market improves - and I don't see that happening soon. So I thought it time to try a different business area.

Modern investment trading relies very heavily on technology. Computers are now involved in nearly every corner of large banks' trading activities - a big change from more manual processes over 20 years ago. It would certainly be impossible to run a EGB primary dealership without significant technology expenditure. This post details an overview of the technologies I saw on EGB desks.

In Java work, J2SE was used exclusively. J2EE has a very bad reputation as too slow and process heavy. Spring is common. JUnit is used everywhere for unit testing. Same with Jira for bug tracking, but each place I've worked used a different build/deploy system. Eclipse is the most common IDE, but IntelliJ has a few vocal adherents - generally coders can use any IDE they want (as long as it's free).

Servers were always Linux machines. Developer and trader desktops used Windows - as people are more familiar with those. Both desktops and servers tended to be quite powerful machines, and replaced every couple of years. A trader often had 2 or 3 PCs under their desk (if for no other reason than to run their 6+ monitors). Server side processes were split across multiple machines. One EGB desk had over 20 production servers dedicated to their systems - the others were not far behind. There was a constant push from infrastructure IT teams to use virtual servers to save money, but that never happened with anything that involved pricing or quoting. Speed was vital and we had the money.

The whole system was made up of many little programs - most doing a single task. Any diagram describing the flow of data around the whole system quickly became a mess, even without considering external systems. There would be separate applications for position-keeping, risk, tracking obligations, connecting to markets, negotiating RFQs, straight-through-processing (STP - where a trade automatically goes through to backend processing), often a few for pricing, and many more. However a trader would normally view and control the internal EGB systems through a single monolithic GUI. If more than one GUI was required it would always generate complaints. Speed complaints around trader GUIs were also very common - understandably because they did so much.

Trading necessarily requires dealing with external systems, both outside and inside the bank. We would need to pass on our data (via STP) to other bank teams for clearing, settlement, accounting, compliance, reporting. Similarly we would take in instrument static data (information like a bonds payment structure, credit rating, maturity). Externally we would connect to multiple markets for quoting, pricing and trading. Inside the team communication was sometimes done over bespoke socket or Java RMI, but more normally via Tibco RV or Ion Marketview messaging systems. Inside the bank RV, IBM MQ or Tibco EMS were both commonly used. RV is well-entrenched in banks and always had a team dedicated to its support, although everyone seemed to be looking for better.

Databases weren't used extensively. Mainly for initialisation data and historical data. Anything that was needed for pricing was cached in memory or passed over low-latency messaging systems - a database is just too slow. Their second-class status meant little effort was put into their design. Sybase was quite common. Oracle and SqlServer were around too. MySql was strangely absent.

Tick databases, in particular KDB, were also used to varying extents. These are databases specially designed to hold large amount of time-series data. We used them to store every future price tick, every bond price tick and more. Gigabytes of data per day. This data could them be used to analyse market events in fine detail or back test new pricing algorithms. At one bank we implemented a future pricing algorithm that people (including traders) believed gave better prices. At the next bank I worked the same algorithm was back tested with data from KDB and proved to offer no benefit.

Each market had their own API. These were regularly updated. To get around the constant work of writing their own gateways to the markets, many banks bought market gateways from Ion. They specialise in technology for fixed income banking and started with the market gateways and a messaging bus to tie them together called Marketview (often abbreviated to Mkv). They now produce a number of other applications now to do nearly everything in bonds technology - pricing, quoting, RFQ negotiation, a GUI, position keeping and more. Every EGB team I worked in used Ion products to some extent. But I would be surprised if anyone outside for fixed income has heard of them - it is a bit of a niche skill.

Ion were commonly hated by management. The company was adept at extracting the most money from banks without them deciding to go it alone. A few banks did try that (including one where I worked), but came back to Ion when they realised the costs involved in writing bespoke gateways. I found Mkv an acceptable product. They do messaging in a strange non-standard, but it worked and that is what counts to me.

Most EGB systems were bespoke and written by the EGB team. Utilities like messaging and databases were purchased from vendors. It was believed that having our own systems which exactly matched the traders needs was a competitive advantage. Also, we were incredibly more responsive to traders' functionality requests. Ion applications and Bloomberg were the main exceptions. All the traders have Bloomberg terminals and used them extensively for market research. Bloomberg was generally considered the authoritative source for financial information or maths. On two occasions I produced application that differed from Bloomberg in their mathematical outputs. Both times I proved to everyones satisfaction that my work was correct and both times I was asked to change it to match Bloomberg because "that's what everyone uses". On one of those occasions Bloomberg fixed their system a month later so I had to change my application back to its original algorithm. Bloomberg have a reputation for changing their system without prior notice - the first time IT teams become aware of the change is when their systems break.

The monitoring of production systems is omnipresent. Whenever a new system is delivered, one of the first questions support will ask is "how can we tell when it goes wrong?" Every bank I've worked at has a different monitoring system. This always includes a system to scrape log files checking for errors or other key terms and then flashing them up on support's screen. Server resources and network traffic are similarly monitored. Java applications often have JMX interfaces or bespoke administration tools.

Much of modern trading is controlled by computer. Certainly all the routine parts are automated so traders can concentrate on more complex issues. This includes updating prices and quotes for changes in the yield curve on a millisecond scale. It also means trading on behalf of the trader. For example, a EGB flow desk at a large bank will receive (in the good times) thousands of RFQs on the D2C markets every day. A trader would be overwhelmed trying to deal with all these, but in reality over 90% are dealt with by an autonegotiation system and never seen by a trader until it appears in their PnL. This program automatically works out a price to quote based on rules based on various parameters including the type of bond, our internal price, the quality of the potential client (referred to as tiering), and the bank's current positions. A RFQ that falls outside the rules is passed to the trader for a decision, but this is the exception.

Over my time working for EGB desks I was always a Software Developer, and software is the part of the industry I know best. Code written in banks is not especially different to other places, although there is a difference in attitude. This starts before a person even joins a bank.

I started working in banks seven years after leaving university. Thus I have only second hand knowledge of the graduate program. However, I do have very good knowledge of the interview process, from both sides. Due to the high pay available, a lot of people from outside banking apply for banking IT jobs. Normally they don't get interviewed. I was one of them. Over 3 years I applied for tens of banking jobs and only got interviews for 3. I only ever apply for jobs for which I'm qualified, and outside banking would be interviewed around 40% of the time. One investment bank offered me a job and in retrospect I think that luck and good timing were the largest components of my interview success.

Now I have worked in banks I see the greatest impediment to outsiders is the lack of "banking experience". Often job descriptions will have this phrase in the list of requirements. Normally I don't think it is vital, but nontechnical people in particular (HR and agencies) find it a handy shortcut when filtering large numbers of resumes. It is assumed that people with banking experience will among the best (since another bank has already vetted them), understand the business, be able to handle the "get it done now" culture, and have the required mathematical/IT skills. Interviews tend to check the same things.

All of these capabilities can be learnt on the job by a reasonably smart, experienced software developer. Largely because most of them are not a big deal - writing code and fixing bugs is still by far the most important skill a banking engineer requires. Not all the best graduates go into banking straight out of university (indeed not all the best coders even go to university, although I think it does help). The business knowledge is very specific to a particular area - most of my cash bonds knowledge would not transfer easily to derivatives, equities or foreign exchange. A general finance background can help, but most of the time it doesn't matter. The little knowledge required to get the job done will be passed on as needed. Most of what I have learnt was picked up from general interest about how our desks worked. However, I don't think I have ever been to an interview for a fixed income job that didn't ask what a bond's yield would do if the price dropped. Most will ask more - "how are bonds priced", "how do you bootstrap a yield curve", and "how is risk calculated" are all common. I would guess they are checking that I have picked up some knowledge while working on EGB desks, but these questions were asked even before I had that history.

Maths questions are also common at interviews. I don't think the maths I have used in my job has ever gone far beyond the high school level. Confidence in your mathemathical skills is definitely a requisite (especially when a trader is testing you), but basic algebra is good enough for 90% of the job. The other 10% is numerical analysis, linear algebra and being able to understand calculus. Calculus equations are common outputs of the quants' work, and I can certainly see the requirement for them to have exemplary maths skills. Although as a developer, the hardest it gets is understanding a quant's work. Not as bad as it sounds as most of the time there is a reference implementation in Excel to follow.

Interviews also contain numerous programming questions and usually a programming test. I have seen these range from silly easy questions to the crazily hard. Although over time I have seen a pattern emerge - the same type of questions come up over and over again. Again I'm not sure they are relevant to the work we do. If you have a banking interview for a Java position, brush up on pre-1.5 multi-threading (despite everyone using the new java.util.concurrent classes nowadays - but the tests were written before they were added), garbage collection and collections. I remind myself of these things before interviews and they never fail to come up. Writing or explaining a blocking queue with wait/notify is a particular favourite. Also writing code on paper is very common, but the marking criteria can be obscure - try to discuss your answers with the interviewer if possible to explain yourself. One colleague marked a coding question wrong due to inefficiency because an applicant used String.reverse() rather than writing a bespoke reverse method - who ever does that on the job! Another non-banking applicant I liked got rejected because their neural network home project was not up to the standard of one of the other interviewers. I was impressed that had a home project. Sometimes I think the implicit belief that banking people are the best makes interviewers unnecessary dubious and harsh on non-banking people.

The biggest real problem a non-banking programmer will have moving into banking (as opposed to the many imagined problems) is the culture. Although this is usually only evident after starting work. Developers have to produce results quickly and accurately, usually on their own. The most important thing is to get a steady stream of functionality and bug fixes out for the traders. Management's attitude is generally "you should know what you are doing, so just do it". There is very little structure except what you create for yourself. Front office developers need to do a good job and know the best place to cut corners with minimal affect on code quality. The codebase soon becomes a path-dependent mess, so developers also need to be good at quickly diagnosing bugs and short-term hack fixes (if you're lucky there will also be a long-term proper fix).

If a problem occurs there is an expectation you will be available to fix it. People are regularly called on weekends, late at night or early mornings. Once a person was contacted to fix a bug in their code while they were on an overseas holiday. It was considered impressive he managed to fix it while still away. Early morning starts were very common. There was usually a rota for 7am starts to backup the support rota. Although if you released code to production it was expected you would be in early the next day just in case there was a problem. There wasn't a proper hours culture - you could leave early or work from home if required with no repercussion, but it was normal to stay until the job was done. Once I stayed at work until 11pm to finish and release a system, then was back at my desk for 7am to support it (although that is nothing compared to some of the bankers). Another time I stayed back 4 hours just in case a person with a production bug needed help. These are not uncommon, at every bank where I worked most of my team members will have similar stories. For me it was a matter of loyalty to the team (I used to get very annoyed if I felt managers were taking advantage of this). Still I count myself extremely lucky I never had a Blackberry.

Every EGB team I was in had around 10 developers. There were normally about as many concurrent tasks requiring quick completion as there were team members. About 80% of the time people worked by themselves on a particular system. Occasionally a team of two or three developers was used on larger systems. There was always more to be done. Thus most of the time you were responsible for your delivery and had to be individually productive at cutting code. Generally there was no place to hide if you weren't writing code Similarly if you were writing buggy code, you would be spending time fixing bugs and not moving forward. Still at different banks there were differences in expected tempo. The workrate management expected of us in an American bank was greater than when I was at a European bank. Talking to coworkers suggested this wasn't an aberration. Goldmans reputably requires the greatest effort from its developers.

The level of software development process followed depends largely on the team themselves. If they want it, but maintain the existing workrate, they can do it. However, more process tends to slow people down, but too little and an unmaintainable mess is quickly produced. People hung up on process didn't do well, but neither did people with no process. The result is a sort of half agile process. Everyone iterates (usually 2-3 week iterations) and uses a continuous build server. No one pair programs. Unit tests are left up to the developer and coverage varies wildly. Most teams I have seen have try daily standup meetings, but they don't survive long. All the teams had testers, but they were always overloaded by the volume of work and most didn't have a good understanding of the business area. Much of the time systems or fixes were deployed without being tested by anyone other than the developer who wrote it. Knowing that a bug could cost a great deal of money (even being out of the market has a large opportunity cost) promotes paying attention to little details. Thinking through as many failure states and edge cases is very necessary - if you don't catch a potential problem in a system, it will probably be a trader who finds it (at the worst possible time). Often this means you don't make the same mistake twice. For instance, the need to support bonds quoted by yield, as well as the more usual price quoted bonds is now burned into my memory.

Over many years of work, I have only once seen a written specification. Often the specification is just a quick description from a trader - if you're lucky. Sometimes it is passed through a few levels of translation first. If elaboration is needed then often you will get a dismissive "just make it work and don't lose me money". IT people are generally considered as second class citizens by bankers and traders (although there are always exceptions). Once when asked how a system should look, a trader replied "make it look like Lehmans' system". This was years since Lehmans went bust and no one around had even worked there - we just did what seemed right. Another system I delivered was complained about by the traders. After listening to them I produced a bunch of fixes the next day. They complained again and sat me down for 10 minutes to explain what I had done wrong. The next day I reverted it back the the original system delivered two days previous. They said that version was ok and I should done that the first time - no joke, that really happened to me! It is a benefit to have your clients (the traders) so close and quick to specify when there is an issue. However, they are vociferous in their annoyance if something is not right and quiet in their compliments. If we heard nothing about a system we assumed it must be working well.

When something is wrong with their IT systems, traders will either complain to their support people or their front office developers. This is regardless of the source of the problem. As the team facing the traders, it is always us who have to diagnose the problem. On the many occasions the source of the problem is downstream from our systems, we liaise with the people responsible to fix it (a task that generally falls to whoever is around or was originally contacted). Other IT teams are normally helpful, although often don't have the same sense of urgency as front office teams.

The work environment is always noisy. The closer one sits to the traders the higher the volume. People listening to music on headphones is very common. Interruptions are common. Support issues can be raised at any time and it expected that everyone will regularly check the support message channels. It is essentially impossible to concentrate for long stretches. Developers can't be precious about getting into a "flow" state. I used to say "I am always interruptible" - might as well embrace what will occur anyway. Of course this affects the speed and quality of coding.

Most of the development work at banks is not much different to non-banks. Moving data around, transforming it and displaying it to users is the vast majority of the work. Quants may do more research or math based work, but not the "normal" developers. Adding extra functionality to existing systems is most common, followed by bugfixes (tactical or strategic). Least common is writing new systems, but that is what most coders want to do. There is some competition and lobbying when it comes to writing to new systems. A bit rewrite typically comes along every few years as technical debt increases and circumstances change (for instance if other banks are beginning to take advantage of a slowing pricing system in relative terms). Developers have a great deal of latitude in the design and implementation of new systems. It can be very rewarding. Many say that writing new systems (and the high pay) are the only reasons to work in banking IT. I don't think that is far from the truth.

Calculating the price of an EGB bond has to be fast. A big bank may have 400 or so European bond obligations and the quotes need to be recalculated quickly when the market moves. It is possible to recover from incorrect prices on D2C markets, with their negotiable RFQs. However, if an executable D2D quote is wrong then the trader will likely lose money.

It is vital to detect when the yield curve moves and reprice appropriately. For EGBs the yield curve is driven by German bond futures traded on the Eurex market in Frankfurt. These futures are derivative contracts to deliver a specified German government bond at a future date. There are a number of them categorised by the maturity of the bond to be delivered. The Schatz delivers a bond with a remaining maturity around 2 years in the future. The Bobl delivers a 5 year bond, while the Bund returns a 10 year and a 30 year bond for the Buxl. The contracts last 9 months and new futures contracts are created every 3 months. So there is always a current contract with the correct tenor. Every quarter the futures used in the yield curve are converted to the current contract. The point every quarter where the new futures take over from the old contracts is known as the "futures roll".

For example at the moment there are three Bund futures contracts available for trading - expiring in December 2011, March 2012 or June 2012. This month the December contract will expire and be replaced with a September 2012 contract. When the December contract matures those that are short will have to deliver German bonds maturing in roughly 10 years to those with long positions. The contract will list a basket of bonds which may be delivered. The cheapest of these is known as the Cheapest To Deliver (CTD) and is always the one which is actually delivered. Normally the CTD does not change during the length of the contract, but a basket is specified to make it hard to manipulate the futures price.

There are also Italian Government bond futures, but I haven't heard of these being used for pricing, just hedging. Even if they were used for pricing I can't imagine it would be for anything other than Italian bonds, whereas the German bond futures affect the entire Euro bond market.

The Schatz, Bobl and Bund futures are the most liquid instruments on the European yield curve and so are used for the 2, 5 and 10 year points. The relatively new Buxl contract is increasingly used as the driving point at the long end of the curve. Although there is some question over its liquidity, so some places may use swaps or a specially computed point instead. Below the 2 year mark Euribor futures are used to drive the curve - although I haven't dealt much with the short end. I've seen curves with other instruments like swaps, but for EGB pricing the German bond futures are always the dominant drivers. If a future changes value then the curve adjusts slightly and the bond prices are recalculated.

Bond prices are determined using a spread off the yield curve at the point corresponding to the bond's maturity. The size of the spread is determined by credit risk plus liquidity or other terms. Some banks may have a yield curve for each Eurozone country despite them having the same currency and central bank. Visualising these country curves better capture the credit risk of each country and a quant once suggested it also aided pricing. The German curve is the closest to the idealised curve, as it is the safest country. Other countries then spread further away until Greece is reached, clearly worse and separate from the core. As all these curves are based off the same futures, they all move roughly in sync with each other as the futures move. Sometimes they move separately if a country's perceived risk changes relative to the benchmark - the Bund future.

Thus European government bonds generally move in known ways relative to each other and the futures. This can be used for hedging. Traders are constantly aware of the interest rate risk they are taking with their positions (using DV01 as described in Part 1). Generally they are supposed to keep their risk flat - that is close to 0. They will have a set risk limit and every night their positions will be checked against this limit. Regularly or excessively exceeding your limit is a serious offence. Trying to hide being over the risk limit is one of the definitions of a rogue trader. EGB traders generally are not supposed to take risks and so have relatively low risk limits. They are considered flow traders, working to create business with clients and this doesn't require them to take risks (although some do take small'ish risks). They are not supposed to be trading for the bank's account (like proprietary or prop trading). Instead they keep their positions small and take a small cut of a large flow of trades with clients (or at least that is the theory). It is supposed to be steady money, without taking any directional bets, just taking the spread difference between the D2D and D2C markets. When I started a quant explained to me that an EGB desk should not make huge amounts of money, but should never lose money either.

When a position is taken, to keep their risk down the EGB traders hedge. That is they trade something else in such a way as to counteract the interest rate risk of the original trade. Thus the two (or more) trades when combined result in flat risk. The obvious way to do this is just to do the reverse trade. That is if a trader buys 10 million of a bond from a client, then immediate turn around and sell the same bonds to someone else. Thus the total position is zero and the risk is zero. However, this is not normally profitable (due to the spread). There was a beginner trader who liked to do this - he constantly lost money in a booming market and was sacked after a few months. Normally it is necessary to hold onto a position for some time before trading out of a position profitably, so other means of hedging are utilised.

Usually hedging means trading the German bond futures. With every futures roll, the proportion of each future that offsets each bond is calculated (usually by the quants). Thus at a point in time a trader may known that for every million in a bond they hold, selling 500,000 Bunds and 200,000 Schatz will offset their risk. This works as the futures are more liquid than any particular bond and the spreads are tighter. Of course the fact that most Euro bonds are hedged with futures is one of the reasons they are so liquid. The Italian bond futures and swaps are also used for hedging on occasion, but the German futures are the most popular. The liquidity in the futures market also means that traders use various strategies to eke out a little extra profit without too much risk. For example a trader may only hedge half of what they need immediately if the market is moving in their favour, hedging the rest a little later at a better price.

Hedging out interest rate risk does not mean there is no risk associated with holding a position. Credit risk is still present. Imagine a Spanish bond is hedged with the German futures. What happens if the Spanish yield curve moves independently of the German curve, because Spain's credit risk changes relative to the rest of Europe (or at least Germany). At this point the hedge breaks down and the trader either makes or loses money depending on their position. This is what is happening right now in the debt markets. Italy is seen as an increasing risk versus Germany and thus its yields are rising. Anyone long Italian bonds hedged with short German futures is losing money. I know this is happening to some people at the moment.

Theoretically it is possible to hedge away the credit risk with Credit Default Swaps, which is basically just insurance on a bond issuer's default. However I never saw this used - I'm not sure why, perhaps the cost was too high or it was seen as unnecessary. Instead EGB traders either ignored credit risk (the likelihood a country in the Eurozone defaulting seemed very remote until recently) or just didn't keep their positions for long.

EGB desks are not like High Frequency Trading (HFT) desks where the length of time a position is held can be counted in milliseconds. Normally it is hours, or often days. If the position was very large the traders may skew the price to encourage others to hit their prices, or ask the salespeople to work away their inventory. In any case, a position is rarely held to maturity. I know of a few bugs in risk systems at large banks related to maturing bonds or futures and which have never been fixed because "that situation never happens" (as a trader once said to me about futures). Holding an instrument to maturity doesn't involve much profit, but does involve extra bureaucracy and paperwork (especially for futures with the delivery of the relevant underlying bond). It's easier just to flat the position before maturity.

As previously stated, the two main components of a European government bond's price are interest rates and credit risk. Credit risk is basically the risk of the country defaulting. This risk is driving European bond prices at the moment. Prices rising for this reason is often called the result of "bond vigilantes" - traders punishing a government for its poor finances and worsening position. It is claimed that austerity will save us from these vigilantes. Although such claims from politicians ignore the other factor driving bond prices. A country heading towards a recession will likely lower its interest rates in the near future to stimulate its economy. Alternatively, in a booming economy interest rates tend to rise. So other things being equal, if a country's economy is slowing then the yield of its bonds is likely to decrease in the expectation of lower interest rates from the central bank. This is what we are seeing in the UK, credit risk hasn't changed much but with a recession likely or at least a weak economy, bond yields are at historic lows.

EGB traders keep an eye out for any news that may affect these factors. Millisecond to millisecond pricing is done by the futures driving the yield curve. So traders instead use expectations to adjust spreads, grow or shrink positions for a little profit (within their limits) or turn off quoting in advance of expected volatility. If a large or step change in futures' pricing is possible, then turning off quotes until the market has settled lessens the likelihood of making a trade which a bad a few milliseconds later (and thus meaning the hedge is done at the wrong level). This often occurred around big economic announcements which could quickly change views of an economy's direction.

Quoting was always turned off for the largest economic news - monthly US non-farm payrolls (often abbreviated to just "non-farm"), announced on the first Friday of each month at 8:30am New York time (usually 1:30pm London time). The payroll figure describes the number of jobs created (or lost) in the US economy over the previous month along with average pay rises and hours worked. This gives an indication of where the US economy is heading, and thus the world as the US is still the largest component of the world economy. If the US is booming, it is more likely the rest of the world will be too - and vice-versa. The neutral payroll figure is around 200,000 jobs created in a month, as this matches the monthly workforce increase in the US (it is a big country!). Thus lower jobs figures suggest lower bond yields and higher job figures imply higher bond yields.

As always with such economic indicators, it is the difference in expectations that has an effect. In the days leading up to the announcement analysts try to predict the figure and the consensus of these expectations are built into bond prices. When the real figure is announced the prices are adjusted relative to the expected figure. Thus if the market expects a payroll gain of 20K and the announced figure is 80K gained, then yields will rise despite the small gain suggesting a slowing economy.

Resolving the difference between reality and expectation can cause bond prices to jump. This creates lots of noise on the trading floor. Someone junior normally has the job of shouting out the figure as it is released. The more surprising the announcement, the louder the shouting afterward. When the series of bad payroll numbers came out during the financial crisis, the traders cheered loudly. It seems perverse to cheer US job destruction, but as previously stated traders only look at their personal PnL, not the wider picture. In this case the traders had permission to build up a long position and so the falling yields after a bad number made them money.

The noisiest I have heard a trading floor was immediately after non-farms during the start of the financial crisis and the day after Lehman's went bust. On these occasions it got close to the levels seen in movies when there is a panic. Trading floors are generally noisy places with lots of desks packed together. There are always people shouting instructions, conversing or talking on phones. TVs are constantly on but with the sound turned off unless something big is happening (terrorist attack, Lehman's collapse, the Ashes). The most annoying noise is the computers. Traders often have their PCs set up to play a noise on various events: a trade done, RFQ received, large price move, etc. So there are constant laser blasts, ka-chings, buzzers, animal sounds, movie quotes and more. It can be hard to concentrate with these intentionally attention grabbing noises. Traders don't seem to mind too much, they are constantly focussed on the present - though not so good for programming. Strangely one noise almost never heard on a trading floor is a mobile phone ring. Banks like to record all communication for compliance reasons, so personal mobiles are banned or discouraged as they can't be recorded.

There is probably more to EGB trading than the above - but this is what I have seen and had explained to me.

When I first interviewed for a technology job in fixed income, I knew the "basics" and explained how to to a discounted cash flow analysis to price a bond. The interviewer smiled and said yes, that was the correct way to price a bond, but that wasn't how it was done in practice.

On D2C markets trading is a negotiation. When a potential client wants to buy or sell a bond they send a Request For Quotes (RFQ). This RFQ can go to a specfic banik or multiple banks at once and starts a negotiation process. The banks send back their quotes and the client chooses one quote or makes a counter offer and so on until the price is agreed and the trade done or alternatively no agreement is reached and the RFQ canceled. Banks can send prices to the markets (know as quotes), but these are usually just indicative - that is a price at which they are likely, but not necessarily, willing to trade. It is like advertising. RFQs ensure that trade is done at a price with which the trader (and client) is happy. Thus they should be profitable for the bank unless there is an error somewhere or are intentionally done at a bad price (perhaps as a favour to a client or to offload a large position). Some D2C markets allow "firm pricing", where the quoted prices should be executable - that is the published price is the final price, no negotiation involved. However, they are not really executable and the trader still gets a last look to ensure the firm price is good (the downside is that if they reject too many firm price trades the market will stop them sending firm prices). To get around the possibility of a bad trade with firm prices the traders send quotes with wider spreads than for indicative prices (ie. the prices are worse than might otherwise be available). Banks almost never send RFQs on D2C markets. The spreads are tighter (and thus the prices better) on the D2D markets.

Government bonds can also be traded on D2D markets (but not corporates). The main D2D market in Europe is MTS. There are a few others, but MTS is by far the biggest. D2D markets use strictly executable quotes. If a price is quoted and someone else trades at that price, then the trade is done - no negotiation or last look. The terminology is that if your quote is traded then you have been lifted, if you trade on someone else's quote then you have hit them - although at times I have heard the terms used interchangeably.

Executable quotes make the D2D markets a very different place for traders. If a trader is quoting an incorrect price and it is lifted then they lose money with no chance of avoidance (other than not having a bad price). The likelihood of having bad prices hit is very high as all the other market participants are sophisticated traders - other large banks. Generally if some other bank is initiating a trade with you then you are getting the worst of it. There is little motivation for them to lift your quote if it is the correct price (unless they are trying to move inventory or have an error of their own). Most traders hate quoting on the D2D markets.

So why do banks quote on D2D markets? Partly it is because quoting is seen as integral to being a "real bank" and that the D2D markets gives banks access to government bonds cheaper than D2C markets. However, the main reason is they are forced to quote. European governments like to have liquid secondary markets in their bonds. If potential buyers know that their government bonds can be easily resold, then the initial price they are willing to pay at issue increases. Thus governments can pay a lower rate of interest. To get the banks to quote in the D2D markets, European governments have set up the primary dealership program. Banks can apply to become a primary dealer in a country's debt. The number of primary dealers is generally restricted, so only large international banks and the country's own banks tend to be approved. The largest recent change in primary dealers was around 2008-09 when some large banks disappeared: Lehmans went bust; Bear Stearns and Merrill Lynch were merged into other firms. This allowed a couple of smaller banks RBC and Jefferies to take up primary dealerships across Europe.

Primary dealers are required to quote on the D2D markets. This is called their "obligations". The government bestowing primary dealership will sent a list of bonds every month together with the length of time they should be quoted, the maximum spread they should be quoted and the minimum volume to quote. For example, the French government may say that its primary dealers should quote a set of 50 French government bonds for at least four hours per day at a spread no greater than 50 basis points and at volume of at least 10 million.

The primary dealers are ranked each month on how well they did at meeting their obligation requirements. This ranking then feeds into the bidding process on government bond auctions. When European governments issue new bonds, they do so at auctions where only primary dealers can bid. The government will state the characteristics of the new bond and banks then bid what they are willing to pay for them. Normally when primary dealers buy bonds at issue they can immediately sell them at a profit on the D2C markets. The gains made at auction (together with the prestige of being a primary dealer) make up for the occasions when quotes are lifted. Although a trader might not see it that way when they have been hit a few times in quick succession.

So far all the trading has been done electronically. That is the trade is completed between computers under human instruction. No open outcry like in old films of the stockmarket. A trader in London may trade with someone in a different country who they have never met or even spoken. In fact the nature of the markets make this very likely. At one former employer, a trader calculated that he had made a large amount of money off one particular person at a competing bank and joked he should send them a Christmas card, but he didn't know their real name (only their market login nickname).

Some trades on the D2C markets still have a human touch. However, this is not from the traders. Alongside the traders (although organised into their own desks) are the salespeople. They work to drum up business. The salespeople themselves aren't allowed to trade (in London you have to be licensed by the FSA), the actual trade execution has to be done by a proper trader. The salespeople try to think up trade ideas for the bank's clients. Essentially justifiction for the client to trade with them. Simplistically, this is of the form, "if you do X I think you'll make money", although I heard rumours sometimes trades are done more as favours.

I have had very little to do with sales desks. So I can't give more than a basic description of their function. I have noticed that sales desks tend to have a higher percentage of women than other front office areas. There also tends to be higher proportion of young'ish good looking people in such teams. Perhaps it makes persuasion easier. On government bond trading desks across 3 different banks, I have yet to meet a single trader who was female and only two who were from an ethnic minority (both East Asian) - otherwise they have all been white European men. This is less the case in other teams. I get the impression that the number of minorities on a trading desk is inversely related to the age of the business of the desk. Government bond trading desks tend to have been around for decades and is definitely a boys club. The newer corporate desks are more varied and the recent ABS/MBS traders were about half minorities - at two places I worked they were run by women.

Trading tends to be a young man's game. Most of the traders I worked with were in their early 30's, with the occasional guy younger or older. However, most of them were younger than they looked! The stress and early mornings weren't doing them any favours. A trader's basic salary tends to be a small part of their overall remuneration. Most of their pay comes in an end of year bonus that is driven largely by PnL. A trader roughly expects some (usually single digit) percentage of their PnL to be paid as their bonus. They monitor their PnL constantly throughout the day. So there is realtime feedback on how well they are doing their job (making money) and know that will directly affect their remuneration. In addition, EGB traders in London start trading at 7am, as that is when the markets in Europe open. Most are sitting at their desks 15-30 minutes before then. Lunch is normally eaten at their desk, only juniors seem to spend significant time away from the desk. EGB traders could always be found during the day staring at their 6 or so computer screens. The trading day ends at 4:30pm London time, but after that is administrative work and meetings - getting out around 5:30pm would be a good day. Very long days - although not as long as I hear investment bankers endure.

Constant financial feedback and long stressful days don't lead naturally to emotional stability. I found traders often at extremes - either very happy or angry. If they were calm it didn't take much to tip them over. The stereotype of the shouty trader certainly has a basis in reality around the EGB desk - if they are losing money. Of course when making money they were nice people. Most of the time I have been working with EGB desks they have been profitable, and the traders generally pleasant. Although, before talking to a trader I (and many others) would first check if they were making money that day. If they were up we would pop around and have a chat. If they were down on the day then we would avoid them.

I have many personal or second-hand stories of highly strung traders at work. However, I have no stories of post-work shenanigans. I never socialised with the traders outside of work, both because I was never invited and I was never interested. Traders shouting and swearing at people is such a standard occurrence the experienced support person soon barely notices it, unless it is extreme or continuous. Dismissive and demanding behaviour was also common. Traders run the place and look after themselves. One trader was well known for demanding that support or a developer come see them immediately, but once they had arrived telling them he was busy and making them wait 5 or 10 minutes before making his normally non-urgent request. Trader's often seem to have a compressed sense of time. When estimating duration they would grossly overestimate. Most support people would smirk at the concept of a trader minute, which actually is only a few seconds long (ie "my prices were wrong for minutes!"). Another time I was sitting with a support person while trying to solve a trader's problem with a market (it was the market's fault). Nearly every minute the trader would call ask for a progress update and when it would be fixed. The support person always replied with the accurate and decreasing time estimate, after which the trader would tell them to fix it now (and not in a nice manner). I could see no way that the problem could be fixed faster than the support person was managing. At least the trader didn't storm around and stand over the support person until the issue was resolved (which I have seen happen).

Losing money really aggravates a trader, especially if they don't see it as their fault. I've heard traders demand we have a trade reversed on the market, even though they know we can't do that. Once a trader demanded that we have the market open early so he could cover some positions (also not possible, we told him to just wait the 5 minutes until 7am). I've also heard of a trader reaching into a support person's pocket to get their wallet in order recover a loss on a trade - although he was just kidding and gave the wallet back unmolested.

Traders also compete with their colleagues to protect their personal PnL. Underperforming traders are often let go - that is a given. Also, within an EGB desk traders are organised by seniority. The most senior EGB trader is normally responsible for bonds around the 10-year mark as that is the most profitable part of the EGB yield curve. Developers are seen as a cost, but if we do something to generate profit it is hidden in the trader's PnL. At one bank we wrote a simple automatic trading system that we believed worked quite well - certainly it was doing a large amount of business and the traders praised it. When this system traded it did so as one of the existing traders as this is required by the FSA, so any PnL gain went to that trader. We told the traders we would break out the PnL for the automatic system so they could see how it was performing - and provide us with a little good PR. The traders were insistent that we shouldn't do that. I believe the main reason (and I wasn't the only one) was to ensure we didn't try to claim some of the profit for ourselves (but as a contractor I didn't get a bonus anyway).

Traders are just the tip of the pyramid - there are a large number of people supporting them. There are the aforementioned salespeople feeding business to traders. Research people produce reports on the current financial environment with forecasts. Quants are the highly mathematical people (usually with a PhD) creating financial models or tools. Sometimes the previous roles merge to some degree - eg a mathematical research person who also does some sales. While EGB traders are often decent mathematicians in their own right (all I know have quantitative science or engineering degrees), quants are usually better. There are various support teams - normally there is a desk of technical support people dedicated to the bond desks. In addition there are phone support, desktop support (for machine problems), marketdata support (for data feeds from the market) and others that handle queries across the whole company. Sometimes support people from external companies (like Bloomberg or Reuters) are also available onsite. Bloomberg was particularly known for typically hiring very attractive young women and sending them to clients as support - the traders were always nice to them! Software developers also do second or third line support if a problem arose with our systems. There always had to be someone around during market hours to field queries. So at each of the three places I worked there was a duty roster for 7am starts and being on-call out of office hours.

Behind the scenes there were also various middle office (risk and control) and back office (compliance, trade settlement & clearance) teams. Although these people often sat in different buildings and I only occasionally conversed with them via email or over the phone. Most IT people were classed as back office, but those of us who interacted directly with traders (and sometimes sat on the trading floor) were placed in Front Office IT, a half-way house. Everyone wants to be attached to a profit centre rather than a cost centre. That made most difference to the permanent employees and their bonus, though still probably at least an order of magnitude or two less than the true front office "money makers".

Front office people are also required by the FSA to take 2 weeks consecutive leave in order to make fraud harder (which included me at 2 of the 3 places I worked). In public this was taken begrudgingly, but in private people were happy for it. Most front office (or teams that aspired to front office status) espoused a hard-working, hard-charging image. We also had to complete various risk and compliance courses (normally given and tested online). These were universally considered a joke - passing required little more than remembering that stealing is wrong.

For the last six years I have developed software for the bonds desks of Investment Banks (usually the European Government Bonds desk). Now it is time to move on into a different business area. So I have decided to write some notes on the business and software of bond trading as I have witnessed it - starting here with the basics.

The instrument described above is a standard bullet bond. It is called a bullet bond because before bond administration was done electronically, the physical bond paper had little tear-away tabs for each coupon payment, and these tabs were know as bullets. Military (and sports) metaphors are common in banking. However, there are numerous different categories and types of bonds. The biggest split is between Corporates/Credit and Rates. Company issued bonds are considered Corporates or Credit and government issued bonds are Rates. Inside all the banks I know about, the two are always separate from a business standpoint (different traders sitting as physically distinct desks) and sometimes so is the supporting technology, but not necessarily. As I have always worked officially with Rates, only incidentally being involved with Credit, the rest of this series will lean heavily towards the world of government debt.

Rates are often further split by business type into separate desks. Here by desks I just mean an organisationally distinct group of traders that have supposed responsibility for a type of security. Although that won't stop a trader transacting in other securities, just that their desk defines their focus or specialty. The desks themselves can be further subdivided, but more on that in the next post.

US government bonds are called Treasuries, and they normally have their own desk of traders (usually based in New York). There is the Gilts desk for British government bonds, and the European Government Debt desk (also known as the EGB or Eurogovvy desk) for dealers of Eurozone bonds. Depending on the size of the bank there may also be desks of traders for emerging markets, supras/agencies (debt issued by non-government organisations that is guaranteed by governments - like the European Development Bank or Fannie Mae) or even sometimes a Scandi desk just for the Scandanavian countries. There is also often a desk of just a trader or two for linkers - inflation-linked bonds where the return is derived from the inflation rate in a country.

Derivatives based on rates bonds also have their own desks - futures, swaps, options, and more. I have had little to do with these desks other than where they interact with bonds desks. Credit also breaks itself into different desks, but I have never interacted with them.

Beyond just different issuers there is also an entire spectrum of different types. Bullet bonds (as used above in examples) is the most common type of bond I have encountered. However, there are many more. Each requires a different calculation to determine their price and have different levels of popularity. Below is a list of some I have encountered on rates desks. There are many more types than listed here.

• Floating Rate Bonds or floaters - the coupon payments of these bonds is not set in advance, but instead floats. The amount paid is determined by some algorithm based on the financial environment at the time (ie. central bank rate + 1%).
• Inflation Linked Bonds or linkers - A type of floating rate bond where the coupon payment is based on an inflation rate.
• Zero Coupon Bonds - bonds which make no coupon payments.
• Perpetual Bonds or perps - bonds that never payback the nominal value and just continue paying coupons forever. There are a few of these issued by the UK government hundreds of years ago and the holders still collect the coupon payments every year.

These are more common on credit desks:

• Callable or Putable Bonds - bonds where the issuer (for callables) or the holder (for putables) can call in the debt under certain conditions - thus forcing payment of the nominal and ending coupon payments.
• Asset Backed Bonds - bonds where the nominal and coupon payments are based on the returns on some asset, for instance pools of mortgages.
• Convertible Bonds - bonds where the debt can be converted into company shares under certain conditions.

A hugely important part of bond trading is knowing what the bonds are worth. In this respect bonds have an advantage over other security types like equities and currencies - the cash flows to the bond holder are known in advance. Thus the Discounted Cash Flow technique can be used to price the bond. From the bullet bond example above, we know that it returns its nominal value ($1M) in 10 years (on the maturity date) and that every year (because the coupon frequency is annual) it also returns a coupon payment of $50K (as the coupon rate is 5% of the nominal). Thus the cash flows of the bond after purchasing it on issue are:

Using DCF and setting the discount rate to the current US Federal Reserve Base Rate of 0.25% gives the present value of the bond as $1,468,534. Thus suggesting a buyer of the bond at issue would be willing to pay upto that amount for it. The interest rate a bond returns, known as its yield, is different to its coupon rate. In the example above, purchasing the bond at issue for $1,468,534 means a yield of 0.25%, despite a coupon rate of 5%. If $1,000,000 is paid for the bond at issue, then both the yield will be 5%, the same as the coupon. So price and yield are correlated, but the coupon is unchanging. The only thing that matters are the cash flows associated with holding the bond and the appropriate yield curve (that is, the expected interest rates). Thus the price of a bond drops, its yield increases and vice versa (a common entry-level interview question in Fixed Income technology). Astute readers will immediately see two problems: the choice of discount rate; and the risk of bankruptcy.

The risk that the issuer of the bond may not repay the debt is known as the credit risk. The higher the credit risk the more likely the issuer won't pay, thus the lower the price of the bond and the higher the rate the issuer has to offer to tempt buyers. Levels of credit risk are categorised by the grades produced by ratings agencies. So other things being equal, a AAA rated bond is worth more than a C rated bond. Countries are generally considered safer than companies, so they pay less of a credit risk premium. However, countries themselves can vary in perceived risk. In the Eurozone, the spread (or difference) over German 10-year bonds (also known as bunds) is the standard measure of perceived risk - as Germany is seen as very likely to repay its debt (it is rated AAA). At the moment German 10-year bonds yield 1.95% while Greek 10-year bonds yield 23.02% (unrated due to likelihood of default) and the French 10-year rate is 2.66% (AAA rated). The Greek spread is 21.07% or 2107 basis points (1%=100 basis points), while for France it is 71 basis points. As both are in the Eurozone, both have their bonds denominated in the same currency and thus their post-issue value is driven by the same ECB interest rate. So the price difference is largely a measure of risk. Unsurprisingly, Greece is seen as incredibly more likely to default than France. Credit Default Swaps are securities to insure against credit risk, but they do not seem to be used much by EGB traders.

The issue with the discount rate is that in reality it is unlikely to remain static for all but the shortest maturity bonds. Instead a changing interest rate needs to be used that accounts for predicted changes in rates. Luckily such a projection of future interest rates exists - the yield curve. The rates to use when discounting a government bond's cash flows is determined by a yield curve for the bond's currency. Below is an example yield curve. As can be seen, the rate changes with time, typically with an upward slope.

The process of constructing a yield curve is known as bootstrapping. First find a set of instruments with maturities that correspond to desired tenors on the curve (a tenor is just a period of time, eg 1 day or 3 months or 15 years). These instruments tend to be the most liquid (effectively the instruments with the most volume available for buying or selling) at the desired tenors. This usually means derivatives of various flavours are used (why this the case is explained in the next post). The interest rate implied by the market price of the chosen instruments becomes a point on the curve. The actual curve is then interpolated from these points (a process known as bootstrapping).

Over the short term bonds tend to trade at a set spread to their yield curve. That is its yield is not exactly on the curve, but at a small distance from it, the size of this distance is the spread. This spread represents the credit risk and any other issues (eg. liquidity) that affect the value of the bond beyond interest rate expectations.

The value of a bond also depends on when the coupon payment is due. A bond is worth more the day before a coupon payment (as the next day the purchaser will get the payment) than the day after (when the purchaser won't get the payment). The amount the coupon payments change the price is known as accrued interest. Traders don't like to calculate how much of an affect the coupon payments have on a price. Thus for the purposes of trading the price is stripped of accrued interest. The price with the coupon effect included is called the dirty price and with it excluded is the clean price. The rough diagram below shows how these concepts are related.

The price calculated may be the actual value of the bond, but it is not where banks want to trade. They want to buy low and sell high. The price at which they will buy is the bid, and the price at which they will sell is the ask (or offer) price. The calculated price is known as the mid price as it is normally halfway between the bid and ask. If it isn't halfway then the actual halfway point is know as the skewed mid and difference between that and the calculated mid is known as the skew. Skews are not often applied in my experience and only if the trader is particularly keen to do a certain trade. The difference between the bid and ask is called the spread (not to be confused with the spread off the yield curve - also known as the spread). The wider the spread, the worse the prices as the further they are from the calculated value of a bond. The bid and the ask prices are sent out to a market by the bank as the prices at which they are willing to trade - the mid is kept hidden. The process of publishing the prices is known as quoting. When quoting, the total nominal value of the bonds willing to be bought or sold as part of the quote is known as the volume.

For example, if a bond has a calculated price of $100, this is the mid. If the trader uses a spread of $1, then the prices quoted are 99.50/100.50. If the mid then moves to $100.50, then the quote is 100/101. If a skew of -0.5 is applied then the quote becomes 99.5/100.5 again (but the mid is still 100.5). If the spread is then widened to 2, the the quote is 99/101.

When working out whether or not a bond trade has made money the term PnL is used (short for "Profit and Loss"). There are two types: realized and unrealized. Realized PnL is the actual cash flow coming from a trade. If you have some bonds and sell all of them, then the price difference between the buy and sell multiplied by the number of bonds is the realized PnL. Thus if you have 1000 bonds bought at $100 and sell 500 at $99 then your realized PnL is -$500 (-$1 per bond for 500 bonds), that you made a loss. Unrealized PnL is the amount of realized PnL that would be made if your holdings are sold at current market rates. Thus if you have 1000 bonds bought at $100 and now the market price is $101, although your realized PnL is 0 (as they haven't been sold), your unrealized PnL is $1000. Calculating the unrealized PnL by comparing the price paid against the market price is known as "marking to market", and is easy in the liquid government bond market. A trader's PnL is considered the sum of their realized and unrealized and is usually quoted on the basis of the difference day-by-day. So if a trader says their PnL is down $100K, it usually means so far they are down $100K that day.

After determining a bond's price, measuring its risk is the next most important concept. The traders need to have some idea of how the value of their positions (that is the bonds in which they are long or short) will change when the market moves. The most common measure of this is DV01, which describes the amount a bond's price will change given a 1 basis point change in yield. DV01 is similar to duration and gives an indication of a bond's sensivity to changes in the yield curve. DV01 is technically only for US dollar bonds. PV01 is the same concept for other currencies (or even other security types), but on EGB desks the terms are used interchangeably (same with pvbp). To get the risk of a position, just multiply the net position by DV01. So if you own $10,000,000 of a bond with a DV01 of 0.02578, then you can expect the value of your bonds to go down approximation $25,780 for each basis point rise in yield (and vice-versa). It should be noted the above is a simplification, as the calculation only works for small changes in yield. Larger changes need to take into account convexity, but that is beyond this discussion (and I've rarely needed that information).

There are numerous other theoretical concepts in fixed income. There are large books devoted to understanding the myriad of derivatives based on bonds. However, the above are the fundamentals as I experienced them. Other concepts or maths came and went as required, but from a technology standpoint I often needed to understand the different types of bond, risk and valuation.

Continue to Part 2a - The Reality

This series provides a brief introduction to a number of current topics researched or studied in the Classics department at Warwick University. The 10 audio-only podcasts are in the format of an interview discussing the topic at hand. Episodes range in length from 21 to 36 minutes. The production quality is generally good, although on the "Graeco-Arabic Studies" episode the audio cuts outs a couple of times. One of the episodes, "The Golden Age of Islam", is in Arabic so I was unable to understand it.

The podcasts range across a number of disparate topics. There is a discussion of Numismatics - which for classical studies effectively means coins. Coinage was first minted in Lydia (in modern day Turkey) around 650BC, and spread quickly. Coins were traditionally made from valuable metals (gold and silver). However to be able to mint more money, the coins were regularly debased. During the 3rd century AD the denarius went from being 50% silver to 1.5% silver. Another podcast (Medicine and Classicism in a Comparative Perspective) looks at how medicine claims classic roots in ancient works and commentaries, like those of Hippocrates and Galen. Apparently Indian and Chinese medicine have similar traditions. Old classical medical books (and alchemy texts) were among the first texts translated into Arabic as the classical world collapsed, as stated in the Graeco-Arabic Studies podcast.

A quip during Drinking Parties in Ancient Greece podcast proposes that classics is really just the history of drinking. This episode describes the Symposium; drinking parties in ancient Greece. Apparently the dancing girls were regularly in danger of being groped. The Sex in the Ancient World episode suggests such dancers must have been disreputable women, as higher class Greek women were neither heard nor seen. Homosexuality in ancient Greek society is also mentioned. There is some debate as to whether the pederastic relationship in ancient Greece was considered homosexual in the way we understand it today or just a traditional cultural institution.

Other episodes deal with the role of logic in the renaissance; Roman elegiac poetry; and epic poetry (subtitled "Homer to Virgil", it could be retitled "Homer and Virgil" as these are the only two poets mentioned). There is also a short biography of Augustus while discussing his autobiographical mausoleum inscription, referred to as the Queen of Inscriptions. Apparently the original is now lost, but three copies exist in modern Turkey.