Tag Archives: quantitative finance

Where to Go from Here?

We started this long series with a pitch for my book, Principles of Quantitative Development. This series, and the associated eBook, is an expanded version of the non-technical introductory chapters of the bookwhat are the things we need to keep in mind while designing a trading platform? Why is it important to know the big picture of finance and banking? Hopefully, these posts have given you a taste of it here. If you would keep a copy of the series handy, you can purchase and download the beautifully crafted eBook version.

Further steps

We went through the structure of the bank from the exotic and structured trading perspective. We talked about the various offices (Front Office, Middle Office and Back Office) and pointed out the career opportunities for quantitative professionals within. The organizational structure of the bank is the apparatus that processes the dynamic lifecycle of trades.

If the structure of the bank is akin to the spatial organization, the lifecycle of the trade is the temporal variation; their relation is like that of the rails and the trains. We spent quite a bit of time on the flow of the trades between the front office and middle office teams, how the trades get approved, processed, monitored, settled and managed. Each of these teams has their own perspective or work paradigm that helps them carry out their tasks efficiently.

Trade Perspectives was the last major topic we touched upon. As we saw, these perspectives are based on the way the various teams of the bank perform their tasks. They form the backdrop of the jargon, and are important if we are to develop a big-picture understanding of the way a bank works. Most quants, especially at junior levels, despise the big picture. They think of it as a distraction from their real work of marrying stochastic calculus to C++. But to a trader, the best model in the world is worthless unless it can be deployed. When we change our narrow, albeit effective, focus on the work at hand to an understanding of our role and value in the organization, we will see the possible points of failure of the systems and processes as well as the opportunities to make a difference. We will then be better placed to take our careers to its full potential.

Other Trade Perspectives

In the previous posts, we saw how various teams view the trading activity in their own work paradigm. The perspective that is most common in the bank is still trade-centric. In this view, trades form the primary objects, which is why all conventional trading systems keep track of them. Put bunch of trades together, you get a portfolio. Put a few portfolios together, you have a book. The whole Global Markets is merely a collection of books. This paradigm has worked well and is probably the best compromise between different possible views. The trade-centric perspective, however, is only a compromise. The activities of the trading floor can be viewed from different angles. Each perspective has its role in how the bank works.

Other perspectives

From the viewpoint of traders, the trading activity looks asset-class centric. Typically associated with a particular trading desks based on asset classes, their favorite view cuts across models and products. To traders, all products and models are merely tools to make profit.

IT department views the trading world from a completely different perspective. Theirs is a system-centric view, where the same product using the same model appearing in two different systems is basically two completely different beasts. This view is not particularly appreciated by traders, quants or quant developers.

One view that the whole bank appreciates is the view of the senior management, which is narrowly focussed on the bottom line. The big bosses can prioritise things (whether products, asset classes or systems) in terms of the money they bring to the shareholders. Models and trades are typically not visible from their view from the topunless, of course, rogue traders lose a lot of money on a particular product or by using a particular model.

When the trade reaches the Market Risk Management, there is a subtle change in the perspective from a trade-level view to a portfolio or book level view. Though mathematically trivial (after all, the difference is only a matter of aggregation), this change has implications in the system design. The trading platform has to maintain a robust hierarchical portfolio structure so that various dicing and slicing as required in the later stages of the trade lifecycle can be handled with natural ease.

When it comes to Finance and their notions of cost centers, the trade is pretty much out of the booking system. Still, they manage trading desks and asset classes cost centers. Any trading platform we design has to provide adequate hooks in the system to respond to their specific requirements as well. Closely related to this view is the perspective of Human Resources, who decide incentives based on performance measured in terms of the bottom lines at cost-center or team levels.

Middle Office

The perspective employed by the Middle Office team is an interesting one. Their work paradigm is that of queues running in a first-in, first-out mode. As shown in the picture below, they think of trades as being part of validation and verification queues. When a new trade is booked, it gets pushed into the validation queue from one end. The Middle Office staff attacks the queue from the other end, accepting or rejecting each entry. The ones deemed good get into a second verification queue. The bad ones are returned to the trading desks for modifications in the trade entries or possible cancellations.

Middle Office perspective

A similar paradigm is employed in dealing with market operations such as fixing rates, generating cash flow etc. Market operations have their own two-stage queues. Note that the whole flow is to be facilitated by the trading platform, which should have the capability to render different views. It presents a queue-based view of the data to the middle office staff, and a report-based view to the Market Risk Management team, for instance, or a trade-centric view to most of the other teams. It is important to each team to have a basic grasp and healthy respect for the work paradigm of the other so that they can communicate efficiently with each other. It is no good ignoring the trade perspectives of the rest of the bank. After all, such trade perspectives evolved naturally out of years and years of trial and error.

Quant Developers

Unlike quants, quantitative developers are more product-centric. Their job is to take the pricing models (the output of the quant effort) and make them deployable and accessible to the traders, sales teams and the middle and back offices. Their primary unit of work is a product because when the product definition changes, regardless of whether it uses a new or an existing pricing model, they have to integrate it into the system. Even if it is merely a product variant, they have to implement all the infrastructure and take care of the approval processes for its downstream handling. For this reason, the work paradigm that makes most sense to a quantitative developer is product-centric.

Quant developer perspective

Compared to the quants, the quantitative developers are closer to the day-to-day activities on Front Office and Middle Office. They view the trades (identified by unique IDs) as instantiations of products. Once booked, they end up in the trading platform database as distinct objects with attributes defined in trade inputs. In addition to trade input, they use market data feeds to price a product in the form of a trade. The trading platform comes with a pricing interface which combines trade information and market data. It also runs in what they call batch moderegularly at a given time of the day to compute prices and sensitivities of all trades. Since it is the trading platform that performs the batch job, the quantitative developers may take care of the associated resources like the grid computing platforms, market data feeds, trade databases etc. In this respect, their product-centric perspective may get diffused into a trade-centric view.


If you are a quant, you are a mathematician with an advanced degree in mathematics or physics. Your work is based on both academic research and professional, peer-reviewed publications. You take your inputs from them, apply your own formidable intelligence to come up with a stochastic pricing model that you think will work exceptionally well for a class of products. You will also need the details of the products. Your output is, of course, a pricing model of your own, or an implementation of a pricing model from the literature. This is your primary work unit.

Quant perspective

In order to make use of this pricing model, it will have to be validated. Then a set of products using the pricing model will be defined and submitted for approval. Once approved, with the help of trade inputs and market data, each of the products can be priced and booked into the trading platform. But such activities are outside the sphere of interest and influence of the quant. To them, how a product is instantiated into a trade is pretty irrelevant and trivial. It is merely a question of specifying the trade and market inputs to the pricing model. Even how various products are derived is mechanical, and all therealwork is done in the pricing model.

This perspective, though accurate and functional for a quant, is pretty far removed from the view of the rest of the bank, which is why quants sometimes have the dubious reputation of being out of touch with the industry. The point is not so much that they have to change their perspective, but they should appreciate that there are other equally valid perspectives held by other business units they interact with, and make an effort to know them.

Trade Perspectives

The last section of this post series is on trade perspectives. In fact, our earlier sections on the static structure of the bank and the temporal evolution of the trade have been in preparation to this last section. In the next couple of posts, we will see how the quants, quantitative developers and the middle office professionals (and the rest) see trades and trading activity. Their views are important and need to be accommodated in the design philosophy of any trading platform.

Where do these perspectives come from and why do we need to know about them? Trade perspectives are based on the work paradigm specific to each business unit. Because of what aspect of the trading activity a group focuses on, they evolve a paradigm, or a mental model, that works best for them.

In order to understand, let’s take a look at how we work with a modern personal computer. The paradigm we are presented with is one of a desk and a filing cabinet. So we have a desktop, folders and files. They have become so natural for us now that we cannot imagine another way of interacting with a computer at all. The Internet, on the other hand, is built on a paradigm of something that hovers over us, which is why wedown”-load stuff from it andup”-load stuff into it. But the programmers and architects who develop such paradigms often do work with different and less known paradigms as well; for instance we have ports and sockets and streams and so on.

If we do not appreciate the work paradigm, we will find the jargon that comes with it mysterious and incomprehensible. This is especially true if we are to work on projects that cut across multiple business units with differing paradigms.

Trade perspectives

To illustrate it further with an example from our trading world, let’s look at how we identify a trade. The quants really do not care about the trade identification number; for them, it is the pricing model that is the basic unit that they work with. The quantitative developer, on the other hand, would like the identifier to be something unique per trade. A structurer would like to have one identifying reference for the trade with possible sub IDs for the individual sub trades that make up a structure. While this requirement is easy enough to implement, the software architecture also has to cater to trade cancellation and amendment requirements from Front Office and Middle Office. What happens when a structure is modified or canceled? How do we find and deal withall the related trades? This problem will almost invariably ends up requiring a link ID in the database. Trade number amendments on a live deal create problem for documentation and operations staff as well, who might demand another immutable external reference number attached each trade. Audit will require integrity and indelibility on everything, demanding database record duplication. As we can see, the perspectives and work paradigms of each business unit translate to often conflicting requirements on the program design at a fundamental level. It is for this reason that we will take close look at the trade perspectives in the following posts of this series.

Summary — Life of a Trade

With that we have come to the end of our discussion on trade lifecycle. We talked about pre-trade activities such as the quant work on pricing model, and its validation by an independent team. On a per-trade basis, we have the sales and credit check activities. Once a trade is initiated, it goes through the initial validation work by Middle Office, followed by regular processing by a large number of teams, such as Market Risk Management for limits monitoring and reporting, Product Control for valuation checks and reserve calculations, and trading desks for hedge rebalancing and risk management. During the termination phase of the life of a trade, it is the back office teams that are active in settlements and reporting.

Trade lifecycle summary

As we saw, most of the activities, especially during the inception and up to the termination of a trade, the trading platform plays a crucial role in mediating the processes and conveying the trade from one business unit to the next. But these different business units work with their own entrenched work paradigms, and their perspective on what a trade is or what their work involves can be radically different from one another. Since the trading platform cuts across multiple teams, it has to cater to these differing perspectives, which is the last section of this series starting the next post.

Chấm dứt,,en,Sự kiện vòng đời cuối cùng của một giao dịch là,,en,nó chấm dứt,,en,Nó có thể được kích hoạt vì nhiều lý do,,en,Dù lý do có thể là gì,,en,khi một giao dịch kết thúc,,en,nó kêu gọi các khu định cư và tài liệu lưu trữ của Back Office,,en,Ngoài ra,,en,nó có thể kích hoạt tiết lộ công khai,,en,ở dạng tổng hợp,,en,bằng tài chính,,en,và điều chỉnh khuyến khích của nguồn nhân lực,,en,Những lý do phổ biến cho việc chấm dứt giao dịch và quy trình công việc mà nó kích hoạt được mô tả trong hình dưới đây,,en,Chấm dứt thương mại,,en,Trưởng thành thương mại,,en,Khi một giao dịch hoặc một quyền chọn đạt đến kỳ hạn,,en,nó bị chấm dứt,,en,đó là phương thức chấm dứt thương mại phổ biến nhất,,en,Bài tập lựa chọn,,en,Nếu ngân hàng hoặc đối tác của nó thực hiện một tùy chọn,,en,Các bài tập có thể diễn ra bất cứ lúc nào trong suốt cuộc đời của một giao dịch,,en,hoặc chỉ vào những ngày cụ thể,,en

The last lifecycle event of a trade is, of course, its termination. It can be triggered for a variety of reasons. Whatever the reason may be, when a trade is terminated, it calls for settlements and documentation archival by Back Office. In addition, it may trigger public disclosures (in an aggregate form) by Finance, and incentive adjustments by Human Resources.

The common reasons for trade termination and the workflow it triggers are depicted in the figure below.

Trade termination

  • Trade Maturity: When a trade or an option reaches maturity, it gets terminated, which is the most uneventful mode of trade termination.
  • Option Exercises: If the bank or its counterparty exercises an option, it gets terminated. Exercises can take place any time during the lifetime of a trade, or only on specific dates, tùy thuộc vào mô tả bảng tính của sản phẩm liên quan,,en,Hàng rào vi phạm,,en,Tùy chọn rào cản,,en,hoặc các lựa chọn loại trực tiếp và loại trực tiếp,,en,có thể vi phạm các rào cản được xác định trước và có thể bị chấm dứt tạo các khu định cư hoặc giao dịch mới,,en,Mục tiêu kích hoạt,,en,Dụng cụ tích lũy hướng tới mục tiêu,,en,chẳng hạn như tích lũy phạm vi hoặc chuyển tiếp mục tiêu,,en,có thể bị chấm dứt khi đạt được mục tiêu,,en,Tháng 11 thương mại,,en,Novation là quá trình đặc biệt mà đối tác thương mại thay đổi,,en,Có hiệu lực,,en,đối tác ban đầu bán giao dịch hoặc quyền chọn cho người khác,,en,Khi một tiểu thuyết xảy ra,,en,giao dịch ban đầu bị chấm dứt và một giao dịch mới được bắt đầu với các đặc điểm đặc biệt,,en,Xác nhận và xử lý,,en,Khi một giao dịch được đặt vào cơ sở dữ liệu nền tảng giao dịch,,en,nó kích hoạt toàn bộ điệp khúc xác nhận và xử lý hàng ngày,,en.
  • Barrier Breaches: Barrier options (or knock-in and knock-out options) may breach the pre-defined barriers and may get terminated generating settlements or new trades.
  • Target Triggers: Instruments that accumulate toward a target (such as range accruals or target redemption forwards) may get terminated when the target is reached.
  • Trade Novation: Novation is the special process by which the trade counterparty changes. In effect, the original counterparty sells the the trade or the option to another one. When a novation happens, the original trade is terminated and a new one initiated with special characteristics.

Validation and Processing

Once a trade is booked into the trading platform database, it triggers a whole chorus of validation and daily processing. Quá trình xác nhận là một bước nhảy giữa các bàn giao dịch trong Front Office và các đơn vị kiểm soát trong Middle Office,,en,Tất cả được trung gian bởi nền tảng giao dịch,,en,Các nhà giao dịch có thể chèn một giao dịch trên cơ sở thử nghiệm,,en,Một khi họ tin chắc rằng đó là một giao dịch khả thi,,en,họ đẩy nó đến trạng thái xác nhận,,en,đơn vị kiểm soát kho bạc sẽ được chọn,,en,Nếu các thương nhân quyết định loại bỏ giao dịch,,en,giao dịch kết thúc trong đống rác,,en,nhưng không bao giờ xóa vĩnh viễn,,en,Bộ điều khiển thường hoạt động trong bốn mắt,,en,chế độ xác nhận kép,,en,Họ xác minh đầu vào thương mại,,en,và các giới hạn kiểm soát, chẳng hạn như số lượng giao dịch được phép cho một sản phẩm cụ thể,,en,Nếu giao dịch vượt qua bài kiểm tra của họ,,en,họ đặt trạng thái của nó thành trạng thái được xác thực,,en,cái nào kích hoạt cấp độ kiểm tra thứ hai,,en,Nếu giao dịch thất bại một trong hai cấp,,en, all mediated by the trading platform. The traders may insert a trade on an experimental basis. Once they are convinced that it is a viable trade, they push it to a confirmed state, which will be picked up by the treasury control unit. If the traders decide to discard the trade, the trade ends up in the trash pile (but never deleted permanently). The control unit typically works in a four-eye, double validation mode. They verify the trade inputs, and control limits such as the number of trades allowed for a particular product. If the trade passes their tests, they set its status to a validated state, which triggers a second level of checking. If the trade fails either level, họ bị đẩy lùi vào trạng thái cho phép các nhà giao dịch sửa đổi hoặc loại bỏ nó,,en,Xác nhận thương mại,,en,Khi giao dịch được xác thực đầy đủ,,en,phần xử lý bắt đầu,,en,Nó liên quan đến nhiều đội và nhiều quan điểm,,en,bắt đầu từ cách xác định giao dịch đến đơn vị thông tin cơ bản cần xác định,,en,Chế biến hàng ngày,,en,Như thể hiện trong hình trên,,en,xử lý thường xuyên diễn ra trong các đơn vị kinh doanh khác nhau,,en,Bàn giao dịch giám sát các giao dịch để phòng ngừa rủi ro và tái cân bằng,,en,theo dõi lãi lỗ,,en,P / L,,en,và ở trong giới hạn rủi ro,,en,Các thương nhân cao cấp có được thông tin chưng cất từ ​​những người cơ sở thông qua quá trình xử lý thường xuyên này và có hành động thích hợp,,en,Văn phòng trung gian đóng một vai trò quan trọng trong quy trình thường xuyên,,en,Họ giám sát mục tiêu và vi phạm rào cản,,en,cố định tỷ lệ và bài tập tùy chọn,,en.

Trade validation

Once the trade is fully validated, the processing part begins. It involves multiple teams and multiple perspectives, starting from how a trade should be identified to what the basic information unit that should be identified.

Daily Processing

As shown in the figure above, regular processing takes place in various business units.

  • Trading Desks monitor trades for hedging and rebalancing, monitoring profit and loss (P/L), and staying within the risk limits. The senior traders get distilled information from the junior ones through this regular processing and take appropriate actions.
  • Middle Office plays a crucial role in regular process. They monitor target and barrier breaches, rate fixings and option exercises, tạo ra dòng tiền,,en,và sinh ra các giao dịch tiền mặt khác,,en,Họ tạo ra,,en,với sự giúp đỡ của nền tảng giao dịch,,en,kích hoạt kế toán thích hợp để Back Office hành động,,en,để thực hiện các khu định cư,,en,xác nhận giao dịch,,en,tài liệu lưu trữ vv,,en,Kiểm soát sản phẩm là một đơn vị kinh doanh khác được nhúng trong văn phòng trung gian, chủ động theo dõi P / L hàng ngày,,en,với mục đích giải thích các chuyển động của họ dựa trên sự nhạy cảm và chuyển động của thị trường,,en,cung cấp một tính toán độc lập về lợi nhuận của hoạt động giao dịch,,en,Tính toán dự trữ của họ cung cấp cho các bộ phận tài chính và nhân sự và ảnh hưởng đến các ưu đãi và bồi thường của thương nhân,,en,Quản lý rủi ro thị trường cũng có một nhóm nhân viên làm việc để thực hiện giám sát hàng ngày về giới hạn giao dịch,,en,chẳng hạn như khái niệm,,en,tương đương đồng bằng, vv,,en, and spawning other cash trades. They generate (with the help of the trading platform) appropriate accounting triggers for Back Office to act on, in order to perform settlements, trade confirmation, documentation archival etc.
  • Product Control is another business unit embedded within the middle office that actively monitor the P/L on a daily basis, with a view to explaining their movements based on the sensitivities and market movements, providing an independent computation of the profitability of the trading activity. Their computations of reserves feed into the finance and human resources departments and affect trader incentives and compensation.
  • Market Risk Management also has hordes of staff employed to perform daily monitoring of trading limits (such as notionals, delta-equivalents etc.) cũng như tính toán VaR,,en,Thử nghiệm VaR căng thẳng,,en,Ở hầu hết các ngân hàng,,en,họ cũng xử lý báo cáo tuân thủ cho các cơ quan quản lý và cung cấp thông tin tình báo ngắn gọn và có thể hành động cho quản lý cấp trên, người quyết định chiến lược giao dịch,,en,Như chúng ta sẽ sớm thấy,,en,trọng tâm khác nhau và cụ thể của mỗi đơn vị kinh doanh đòi hỏi một phép chiếu duy nhất,,en,mà chúng ta sẽ gọi là một viễn cảnh,,en,thông tin giao dịch từ sàn giao dịch,,en,Yêu cầu này là một trong những điều khiến cho việc thiết kế và thực hiện nó trở nên khó khăn,,en,Chủ nghĩa tư bản vs,,en,Tập đoàn,,en,Trong một cuộc trò chuyện gần đây với anh ấy,,en,khách hàng này của tôi đã sử dụng từ này,,en,nhà luyện tập,,en,để mô tả đất nước của mình,,en,Mỹ của A,,en,Ông nói hai mươi năm trước,,en,họ là một nước tư bản,,en,không phải là một người hành xác,,en,đây là một loại khác biệt tốt mà tôi yêu thích nói về,,en, Stress VaR tests. In most banks, they also handle compliance reporting to regulatory authorities and provide concise and actionable intelligence to the upper management who decide the trading strategies.

As we shall soon see, the different and specific focus of each business unit demands a unique projection (which we will call a perspective) of the trading information from the trading platform. This requirement is one of the things that make its design and implementation so challenging.

Trade Inception

The inception events of a trade can be classified into two categories. The pre-trade activities are those that have to take place even before the first trade is booked. The per-trade inception activities are the ones specific to each trade.

Pre-trade activities

The pre-trade activities are related to new product on-boarding and approval. As we saw, in-house trading platforms are designed to be nimble and responsive. In principle, it should take little time for a new product to be on-boarded. The last system I worked on, for instance, được thiết kế để triển khai một ý tưởng sản phẩm mới trong vài phút,,en,Nhưng các kiến ​​trúc sư của các hệ thống như vậy có xu hướng quên con người,,en,các yếu tố liên quan đến quá trình và kiểm soát liên quan đến nó,,en,Như slide trên minh họa,,en,một ý tưởng sản phẩm mới hoặc một mô hình định giá mới bắt nguồn từ công việc của một đại lượng mô hình hoặc một nhà cấu trúc trong Front Office,,en,Nhưng trước khi nó đến bất cứ nơi nào gần một hệ thống sản xuất,,en,mô hình định giá cần được xác nhận,,en,thông thường bởi,,en,nhóm phân tích,,en,Nhóm phân tích,,en,trong nhóm quản lý rủi ro văn phòng trung,,en,Sau khi xác thực,,en,sản phẩm trải qua quá trình phê duyệt quanh co có thể mất vài tuần hoặc vài tháng,,en,và sau đó là một quy trình triển khai chính thức,,en,mà có thể một lần nữa mất vài tuần hoặc vài tháng,,en,Khi quá trình đó hoàn thành,,en,sản phẩm có sẵn để giao dịch trong nền tảng giao dịch,,en,Khi có sẵn,,en. But the architects of such systems tend to forget the human, process-related and control elements involved in it. As the slide above illustrates, a new product idea or a new pricing model originates from the work of a model quant or a structurer in Front Office. But before it gets anywhere near a production system, the pricing model needs to be validated, typically by the analytics team in the Middle Office risk management group. Once validated, the product goes through a tortuous approval process that may take weeks or months, and then a formal deployment process, which may again take weeks or months. When that process is completed, the product is available for trading in the trading platform.

Once available, sản phẩm có thể được khởi tạo như một giao dịch,,en,Mỗi trường hợp giao dịch đều trải qua quá trình xác nhận và phê duyệt riêng.,,en,Yêu cầu giao dịch có thể bắt nguồn từ nhóm bán hàng hoặc cơ cấu trong Front Office,,en,Họ cũng sẽ chuẩn bị bảng hạn và các văn bản pháp lý khác,,en,Khi các nhiệm vụ này được hoàn thành,,en,một giao dịch được đặt vào sàn giao dịch,,en,Quy trình mỗi giao dịch,,en,Những sự kiện khởi đầu này được mô tả trong slide thứ hai ở trên,,en,Một trong những bước quan trọng trong quy trình phê duyệt là kiểm soát tín dụng,,en,Như chúng tôi đã mô tả trước đó,,en,Quản lý rủi ro tín dụng,,en,nhóm sử dụng nhiều công cụ để đánh giá rủi ro liên quan,,en,Với sự chấp thuận của họ,,en,và với sự hiểu biết của các thương nhân về giá thị trường của sản phẩm,,en,một sản phẩm có sẵn trong nền tảng giao dịch trở thành một giao dịch trong cơ sở dữ liệu,,en,Và niềm vui cuộc sống bắt đầu,,en. Each trade instance goes through its own validation and approval process. The trade request may originate from the sales or structuring team in Front Office. They will also prepare the term sheet and other legal documents. Once these tasks are completed, a trade is booked into the trading platform.

Per-trade process

These inception events are depicted in the second slide above. One of the crucial steps in the approval process is the credit control. As we described earlier, the credit risk management team uses a variety of tools to assess the risks involved. With their approval, and with the traders understanding of the market price of the product, a product available in the trading platform becomes a trade in the database. And the lifecycling fun begins.