Flat 16
Chequer Court
3 Chequer Street
EC1Y 8PW
cell: 0781 793 2182
Home page: http://PaulHollingsworth.com
Email: Paul@PaulHollingsworth.com
Objective:
A job working with smart, passionate people that utilizes my 10 years of experience programming in the financial sector. Whilst I am a strong programmer, I am primarily interested in opportunities that will stretch me outside of a purely “IT” role. I am seeking a role that allows me to further develop my interests in mathematics and "interesting" programming while using my expertise in programming and design.
Skills:
Buzzwords for recruiter’s keyword search: C++, template meta programming, Scheme, Lisp, CSharp, .NET, Sybase Ctlib, Java, COM, boost, ATL, multi-threaded progamming, OO Design, TCP/IP, Linux, *nix, Win32, awk, sed, ksh, SQL, JNI, Python, etc.
Good knowledge of financial mathematics, probability theory, calculus (I am currently studying a part-time Mathematics and Statistics degree). I have also learnt a lot about about equity derivatives and methods for valuing and hedging them (solving the diffusion equation using a "grid", the derivation of the black scholes equation, the concept of "replication" and so on).
I consider myself a bit of a "polymath" in that I am not just interested in computer science – I’m also very interested in general mathematics, AI, physics, and so on.
Core strength:
I'm an exceptionally good computer programmer. My core competancy would have to be C++, although I first started coding by writing 6502 assembly code for my Commodore 64 when I was 10 years old.
I have developed a strong instinct for "elegance" in coding and design, and a very strong understanding of correct use of OO principles. I come up with correct, simple and "clean" designs that can be easily adapted over time.
Education:
B.Sc. (Computer Science) University of Sydney.
Final year (1995) completed on exchange at the University of Illinois at Urbana-Champaign with a 4.8 GPA (back then it was graded on a 5 point scale).
I am currently completing 3rd year of a 4 year part-time Mathematics and Statistics degree from Birkbeck.
Books I really like:
Godel, Escher, Bach - an Eternal Braid. This book is full of profound insights.
Employment History ( in reverse-chronological order )
Period: September 2008 - Current
Company: Barclays Capital
Rank: Vice President
I am currently working on the Fixed Income Exotics Risk system within Barclays Capital. The system is responsible for publishing daily PnL and risk numbers to the desk. This was working mainly in .NET, but also with some C++ required.
Period: November 2006 – August 2008
Company: Royal Bank of Canada Capital Markets
Position: Quantitative Developer
Implemented CDO VaR for RBCCM’s risk systems
In the last year I have been the lead developer in introducing CDO VaR to RBC’s risk system. It was a very tough task – particularly given that I was completely unfamiliar with the existing system, and was subject to a very tight schedule.
Our requirements were: Modify our system so that every night it could process 500 market risk and 100,000 specific risk scenarios generated from Toronto based on historical data and a transition probability matrix, and value our entire CDO book in each of those scenarios.
The problem with doing this was always going to be performance. CDOs are in many ways the worst of all possible worlds (from an IT perspective if nothing else!). Like equities, each CDO trade requires loading lots of data in order for it to value (credit default swap spreads on hundreds of different names)... but, like fixed income, each CDO trade takes a long time to value also. The existing system at the time I arrived could barely handle doing all of our overnight risk in 8 hours, let alone doing the equivalent thing 500 times over.
We adopted a sensitivity based approach for most of the 100,000 specific risk scenarios. This didn’t seem too difficult at first – just some simple calculus. But it got more complicated once it became apparent (very late in the project) that we had to "figure out" how to shock each credit spread curve such that it would still build, and only use those resultant credit spreads for the sensitivity based calculations.
That left the 500 "market risk" scenarios that we still had to fully value (we couldn’t just deliver a sensitivity based result for these). This required many performance changes to the existing system so that it could scale to handle the volume of computations and data required.
A big, but necessary, complication in doing all of this was the fact that while we were doing this, we also had to change the system to handle our correlation risk completely differently. Previously, we simply "valued" each CDO by assigning an attachment and detachment correlation which had been previously calibrated per trade based on the current index CDO spreads. But this was clearly no use for analyzing any sort of correlation risk – which is the biggest factor (at least in theory) once you have hedged your CDO using appropriate CDS positions.
Nevertheless, despite all of these difficulties, and mainly due to the strong team that I was working in, by the end of August 2007 we had a system that could do the entire "VaR" overnight in 4 hours. By October 2007 we had successfully delivered our OSFI submission for models based regulatory capital relief, based on our system having already calculated 60 business days of "VaR" results.
Sybase CTlib C++ wrapper
Once the aforementioned VaR project had settled down, I resolved to fix one of the major frustrations I had encountered while working with the exisiting code in the system: We did not have an easy to use, yet efficient, C++ library for talking to Sybase. The only reasonable candidate at the time was Roguewave’s DBTools++ which tied you into using and linking with the rest of Roguewave’s libraries and types.
The problem in general with most C++ “wrapper” libraries is that they tie you down to using the author’s choice of “date” class, “string” class etc.
I wrote my C++ wrapper over Sybase’s “ctlib” library so that it was minimally coupled. It utilized template meta-programming, so that you can add your own arbitrary bindings between Sybase and C++ types with a minimum of effort. This meant that clients of my library don’t all have to use the same C++ types in order to use my library. They can simply define the bindings for whichever types they are using and go with that.
An example of the way client code looks is:
ResultBinder results = connection->buildCommand(“select tradeId, expiry from trades”)->execute();
std::string tradeId;
RBCDate expiry; // some user type - just because this programmer is using RBCDate to store dates doesn't mean anyone else has to
results.bind(0, &tradeId);
results.bind(1, &expiry);
while(results.fetch())
// Do stuff with tradeId and expiry
Under a similarly easy to use interface, the library supports executing stored procedures, performing bulk copy operations and parameter binding (so you do not lose precision when, for example, you need to specify a floating point number for the database).
My library is currently being used by several other developers in the team, some of whom have been writing their own “Sybase bindings” for new custom types that they read out of our Infinity database.
Period: October 2005 – September 2006
Company: Citadel Investment Group (Europe)
Position: Quantitative Developer
I was recruited directly from my UBS job to join Citadel in their newly established High Frequency Trading operation in London. "High Frequency" means algorithmic trading strategies that maximize returns over a period of 60 seconds to 10 minutes.
Initially, I was part of a very small team consisting of myself, one other IT developer and the head trader who had done similar business before working for a different company. I was put to work connecting the trading system or "quoters" to the XETRA exchange, as well as developing the initial trading logic.
A particular emphasis was placed on analyzing and reducing latency – the time it took for an order to reach the exchange, how long it then subsequently took for us to see the effect of that order on publicly available market data, and so on.
The other big project I completed was a process called "Liquidity Finder".
The process sits in between other funds’ trading strategies and the raw exchange interface. To the clients, it looked like the raw exchange interface, to the exchange interface, it looked like a client.
By having all external algorithmic trading go through this process, we could choose to fill any given "client order" destined for the exchange from our own inventory instead, subject to "best execution" rules.
It was a complicated process – in order to perform best execution correctly, and to fill from our own inventory profitably on our part, it had to listen to real time market data and make decisions accordingly. A given order might be performed as several independent exchange market orders, with all of the complicated scenarios that that involved. It had to be fast, but also able to recover properly and not "drop any fills" in the event of a crash or restart.
Period: March 2001 – October 2005
Company: UBS AG (Chicago, then London)
Position: Senior Programmer
Rank: Associate Director
While I was working for UBS during this entire 4 year period, it’s best split up into two sections, as I moved groups internally within UBS.
Sep 2004– October 2005
At UBS I worked for the Equities Quantitative Strategies group. This is the group that writes the models used to price and hedge UBS equity derivatives positions.
I joined this group in September 2004 with the following goals:
I suppose one way to sum up my goals in this move was that while working on the Equity Derivatives Risk Management System called "Canine", there was one aspect of the application that I was not sure I could implement and understand myself, which was the models. With this role I hoped to learn enough to understand that part too.
The most interesting thing I developed while working for this group was a basket decomposition library called "Zephir". This is a library which takes as an input sensitivities to a basket volatility, basket yield and basket price and reports these as sensitivities to the individual components of the basket.
I inherited a buggy, incorrect, "hack"ed version of the library, and rewrote it by writing a generic differentiation engine (i.e. I explicitly coded the chain rule, product rule, and so on). The net result was that it could also recursively handle baskets of baskets, quanto baskets, and so on, with no loss of generality. There were no bugs in the new version of the library. I think that this solution to the problem was very elegant, and I particularly enjoyed the time spent working on this project.
Of course, I also provided support for the deployment of the new library into the bank’s risk systems, and provided direct support to the traders using the systems, explaining how to interpret the numbers that they saw.
Apart from this I was also responsible for improving the overall quality of the C++ code in the models library:
Mar 2001-Sep 2004 – Canine and "Pricing Engine"
Before I worked for the EQS group, I worked on an application called "Canine". Canine is the real-time portfolio risk management system used by UBS equities. It allows traders to see a real-time view of a particular portfolio's Delta, Gamma, Tau/Wega etc. and see it broken down by arbitrary attributes (e.g. they can see their portfolio risk broken down by, say, country, expiration, company etc. etc.).
The initial version of the application had a Java GUI "front end" and a C++ "back end" called the "Pricing Engine". While it offered good performance, it could only handle a limited variety of derivatives, was a "brittle" design, and suffered from many subtle bugs, race conditions and numeric errors.
Over the next 2 years I was the guy responsible for designing and implementing a new version of the "Pricing Engine" component. This re-write was to be done in Java.
The new version of "Pricing Engine" had the following functionality above and beyond the original:
The ability to respond in real time to new positions was a crucial piece of functionality due to the joint development of the "Electronic Volatility Trading" project, which is capable of executing trades independently - the trader first learns about the trade when it appears in their Canine portfolio as a different "Delta" number.
While working on this project over a period of 2 years I developed a sound knowledge of Java, and familiarity with some of the problems unique to "run-time" languages with garbage collection.
The best part about doing this project was all of the classic computer science "Algorithms and Data Structures" work. Additionally, it’s always very satisfying to be given the opportunity to re-write and re-design something.
Period: July 1999 to March 2001
Company: MicroHedge, a Division of SunGard
Position: Senior Programmer/Analyst
Team: Development
In this position I worked on a shrink-wrapped Windows application called "MicroHedge". MicroHedge is designed for professional traders and risk managers allowing them to see a real-time view of appropriate "greeks". It connects to a variety of datafeeds including Reuters, AT Financial and TRACK Data.
While working there I gained a good knowledge of ATL and COM fundamentals.
Projects:
EUREX DataFeed for MicroHedge
I completed connectivity between the MicroHedge application and the recently deployed EUREX Values API interface.
The solution was composed of 3 COM components, all written using ATL/C++:
Using this design, VB clients could write code like this:
Set RequestService = Session.FindRequestService("Enter Single Leg Order")
Set Request = RequestService.CreateRequest("O") ' O stands for Option
Request.Body.GetField("buySell").Value = "B" ' Indicate that this is a Buy order
Request.Body.GetField("noLots").Value = 5 ' We want 5 lots
Request.Body.GetField("prodId").Value = "OGBL" ' Of German Government Bund Options
' etc. Fill in the rest of the information
set Response = Request.Send() ' Send the request to the Exchange, retrieve the response
print Response.Body.GetField("orderNo").Value ' Display information about the order
My understanding of COM fundamentals allowed me to optimize the solution for DCOM using techniques such as custom-marshalling to implement a "smart-proxy".
CBOE AutoQuote feed for MicroHedge
This feed allowed market makers on the CBOE trading floor to use a PC running MicroHedge to distribute real-time bid/ask prices to the exchange system.
In developing this, I also felt familiar enough with the domain now to abstract out a COM "plugin" architecture. The CBOE AutoQuote plugin became the first such implementation - but now, clients were also able to write their own quote feeds to allow MicroHedge to send in quotes to other systems, without requiring development effort on our part. A high point in my career has definitely been standing on the trading floor of the CBOE watching the numbers change on the "big board" above that traders were looking at, knowing that my software was playing a crucial role in the process.
Period: July 1996 to July 1999
Company: SunGard Futures Systems (Chicago)
Position: Senior Programmer/Analyst
Team: DataFeeds
SunGard Futures Systems is a provider of Back Office financial software for the exchange traded derivatives market. The "Octagon" product was the premier system used by nearly all members of the Sydney Futures Exchange to fulfil their accounting and reporting responsibilities. It was written in ANSI C using ESQLC connecting to an Ingres relational database.
During this three year period I worked on numerous projects involved in interfacing the Octagon system with various Exchange DataFeeds. During this period, we also started migrating the product to C++.
Here are some of the highlights:
Reuters Selectfeed
In this assignment I was responsible for rewriting and redesigning the original Reuters-based infrastructure in order to more efficiently retrieve more than 100,000 "Settlement Prices" into a central "Master Database" used by clients all over the world.
This involved completely re-writing and re-designing the existing VAX/C infrastructure as a simpler, but more flexible Unix environment making extensive use of scripting.
The new design was faster, cheaper, and easier to maintain and support.
In recognition of my accomplishments, I was awarded the SunGard 100% Club Award for Outstanding Achievement. What is this? Well, basically you get an all-expenses paid 4-day trip to some exotic location with the other award recipients. (In this case to Maui at the Four Seasons resort.) Pretty nice huh?
Redesign of Feeds Control Mechanism
Following on from the Reuters project, I was tasked with redesigning what was called the "Feeds Control Mechanism" – a legacy "string and chewing-gum" mechanism for coordinating our London Data Center operations. The existing mechanism wasn’t really an automated system at all, but rather the same duplicate C code cut-and-pasted into the source code of each datafeed. A set of poorly factored database tables were used to store configuration information, and to provide synchronization between the various datafeeds. The net result was that each program was tightly coupled with the control logic, and even the most trivial maintenance changes were release nightmares.
It frequently didn’t work properly, requiring manual intervention and costly delays.
Going above and beyond the "call of duty", I designed, implemented and deployed into the existing 24hr production environment a highly configurable Scheduler. The new scheduler allows each datafeed to be completely oblivious to the dependencies it had on other operations. It also provides a consistent and ‘intelligent’ operator shell for supervising and monitoring.
The new scheduler deals with configuration management, holiday processing, monitoring and error handling issues, on both UNIX and VMS platforms, and completely replaced the old mechanism, which we happily scrapped.
The key to the flexibility of the new design was the use of a "Scheduling Language" written using YACC and ANSI C.
The key to its successful deployment was an in depth knowledge of the existing legacy system and operational environment.
Period: January 1996 to July 1996
Company: SunGard Futures Systems (Sydney)
Position: Programmer
Team: Octagon Development
In this entry-level position I was responsible for developing a working knowledge of the more than two million lines of C/ESQLC code that makes up the core of the product.
After demonstrating my skills, I was offered the opportunity to transfer to the Chicago office in order to play a more active role in development.