Opinion Piece: My Experience as a Front Office Developer in an Investment Bank
Disclaimer: Experiences are from my perspectives and varies between companies (even between teams within the same company). These are simply reflections on my time in the company (in case I forget what I did 10 years down the road) and to provide some generic information to people interested to find out more.
Fresh out of university, I started my first full-time job in the technology division of a foreign investment bank in Singapore. The bank offers a wide range of services spanning investment banking, sales and trading, asset management, private banking and consumer banking. As for me, I was placed into a technology role supporting sales and trading desks in the region. Some may term it as a front office developer.
What is a front office developer?
There are other names like quant developer and strat, depending on the company and the exact scope of work. The distinction is sometimes blurred but we’re usually kind of working on similar stuffs.
A term used mainly in the context of the finance industry referring to developers alongside front office teams. In a bank, the front office commonly refers to the sales and trading desks. In the buy-side, the term would likely refer to the investment, portfolio management or trading teams. A front office developer basically takes care of the systems used by the front office teams.
What do I do daily?
The scope of work for a front office developer varies between companies. It could range from pure production support, building of database services, coding of valuation models, building exchange connections etc. It is similar to a software engineer in many firms, probably with the exception of the end users and some requirement for finance-related knowledge.
The things I did on a daily basis follow pretty much the typical software engineering workflow:
- Stepped through lines of code to answer queries from stakeholders on the behaviour of processes within the applications they used
- Investigated production issues by going through process logs, checking for recent code changes, rerunning processes, debugging code, checking for data integrity issues, reproducing errors locally etc.
- Write, review, test and push code with changes ranging from amending a flag variable to (small components of) new business logic to writing scripts for scheduled jobs
Overview of operations within the bank’s markets division
Working with sales, trading and middle office teams have given me a broad understanding of what they do and their role in the whole operation of the markets division. I learnt about what happens in the bank after a salesperson or trader makes a trade — trade capturing, regulatory reporting, trade lifecycling, risk and profit-and-loss (PnL) computations. I also observed how different systems (such as the pricing engines, market data, reference data etc.) interact with each other. Since my team supports the applications that handle these processes, I naturally built a working knowledge on what goes on after trade execution, from the bank’s perspective.
Working knowledge of financial products
I developed a basic understanding of the mechanics of some financial products. Examples of questions I found answers to include:
- What is a non-resetting cross-currency swap/ overnight-indexed swap/ total return swap (insert more financial products here)
- What are clearing houses and how do they affect discounting
- What are day-count conventions, business day conventions and calendars, and their relevance in valuation
- How do I calculate the accrual of a bond (factoring in stuff like ex-dividend dates, settlement days, conventions etc.)
A primer into valuation techniques employed by institutions
I had some exposure to the pricing engines that the front office rely on to quote prices and to make decisions. It was an extensive system that covers a variety of financial products (stuff from vanilla to exotic, linear rates to non-linear rates etc.)
Code and documentation were my best friends.
These are great areas to learn about how the processes work. Occasionally, there were also seminars. Having that exposure enabled me to formulate the right questions (to ask Google) and look for the right information.
There was an extensive code base available for reading to learn about how various business processes get implemented from a technical perspective. I was exposed to object-oriented programming, SQL databases, object-oriented databases, job schedulers etc. I had the privilege of working on a platform with many technologists who willingly exchange ideas and share their expertise on organising code.
When it comes to writing code, there was strong emphasis on writing production-grade code (like having good test coverage, good readability etc.) and producing strategic solutions rather than “hacky” ones. Poorly written code could easily snowball into a large problem as it grows and that was something to avoid in critical systems.
A whole bunch of soft skills
I had many stakeholders to manage, some within technology and others from the business. I probably sit somewhere in the middle — which means that I had to do a lot of talking. For example, explaining to middle office why certain outputs are generated within our applications or explaining to other technology teams why the business thinks a particular change is required. There were times where certain stakeholders will raise time-sensitive issues, which really test your creativity and ability to make quick judgements.
Were these things important?
This is a subjective question. I think any knowledge gained is good knowledge.
Programming skills and soft skills are generally transferable so I won’t talk about them.
For domain related knowledge, it depends on factors such as career aspirations, preferred job scopes etc. Personally, as I have an interest in quantitative finance, this experience has been valuable. The knowledge on market-related operations and mechanics of financial products are the fundamentals to understanding higher-order processes or computations.
Several complicated concepts and terminologies are often thrown around. Initially, I wasn’t able to understand things such as curve building, DV01 (dollar duration), CSA (credit support annex), discounting (just to name a few). Even after a year and a half, I probably still don’t know what exactly half of them mean.
But I’d consider just hearing these words or phrases a win.
Some of these can be really deep topics so explanations are usually done at a high level. Nonetheless, they provided good insights into the way institutions do things. I believe that over time, I would be able to better see how these concepts tie in with each other.
It was a great experience that provided a good level of learning, responsibility and interpersonal skills development in a good culture. I made many friends and there were fun events held occasionally, and these are pretty much the icing on the cake.
The experiences described here are very generic as I wish to provide information without revealing too much. If you do have any questions, feel free to drop me a message.