Tag Archives: kantitatif finans

İşte gelen git?

We started this long series with a pitch for my book, Kantitatif Geliştirme İlkeleri. Bu seri, and the associated eBook, is an expanded version of the non-technical introductory chapters of the book — what 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 versiyon.

Further steps

We went through the structure of the bank from the exotic and structured trading perspective. We talked about the various offices (Ön Büro, 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.

Diğer Ticari Perspektifler

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. Bu görünümde, 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, Ancak, 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 top — sürece, elbette, 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 (sonunda, 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. Yine, 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.

Orta Ofis

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, Örneğin, 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. Sonunda, such trade perspectives evolved naturally out of years and years of trial and error.

Geliştiriciler gelince

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. Bu nedenle, 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 mode — regularly 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, elbette, 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 the “Gerçek” work 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.

Ticaret Perspektifler

The last section of this post series is on trade perspectives. Aslında, 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, diğer taraftan, is built on a paradigm of something that hovers over us, which is why we “down”-load stuff from it and “up”-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, diğer taraftan, 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.

Özet — Bir Ticaret Hayatı

Bunun üzerine biz ticaret ömrü bizim tartışmanın sonuna gelmiş. Biz fiyatlandırma modeline Quant iş olarak önceden ticaret faaliyetleri hakkında konuştuk, ve bağımsız bir ekip tarafından doğrulama. başına ticaret temelinde, Biz satış ve kredi kontrolü faaliyetleri var. ticari başlatılır kez, Orta Ofisi tarafından ilk doğrulama çalışmaları geçer, Takım, bir çok sayıda düzenli bir işlem, ardından, sınırları izleme ve raporlama için Piyasa Risk Yönetimi gibi, değerleme kontrolleri ve rezerv hesaplamaları için Ürün Kontrol, çit yeniden dengelenmesi ve risk yönetimi için ve ticaret masaları. Bir ticaret hayatının sona ermesi aşamasında, o yerleşim ve raporlama faaliyet gösteren arka ofis ekipleri ise.

Trade lifecycle summary

As we saw, faaliyetlerinin en, özellikle ticaretin sona ermesi başlangıcından sırasında ve yukarı, ticaret platformu sonraki bir iş biriminden ticaret işlemleri aracılık ve aktarılmasında önemli bir rol oynar. Ama bu farklı iş birimleri kendi yerleşik iş paradigmaları ile çalışmak, ve ne bir ticaret üzerinde kendi bakış açısı ya da ne işlerini içeren birbirinden kökten farklı olabilir. Birden ekipler arasında ticaret platformu kesimler bu yana, bu farklı bakış açılarına hitap vardır, Bir sonraki yazı başlayarak bu serinin son bölümü hangi.


Bir ticaret son kullanım ömrü olay, elbette, sonlandırma. Bu nedenlerle çeşitli tetiklenebilir. nedeni ne olursa olsun, Bir ticaret sona erdiğinde, o Geri Ofisi tarafından yerleşim ve dokümantasyon arşiv çağrısı. Ek olarak, kamu açıklama tetikleyebilir (toplu bir biçimde) Maliye tarafından, İnsan Kaynakları tarafından ve teşvik ayarlamaları.

ticaret fesih ve tetikleyen iş akışı için yaygın nedenleri aşağıdaki şekilde gösterilmektedir.

Trade termination

  • Ticaret Olgunluk: Ne zaman bir ticaret ya da bir seçenek olgunluğa ulaşır, o sonlandırıldı alır, hangi ticaret fesih en olaysız modu.
  • Opsiyon Egzersizleri: Banka ya da karşı bir seçenek kullanması durumunda, o sonlandırıldı alır. Egzersizler bir ticaret ömrü boyunca yer herhangi bir zaman alabilir, ya da sadece belirli tarihlerde, katılan ürünün termsheet açıklaması bağlı.
  • bariyer İhlaller: bariyer seçenekleri (ya-in devirmek ve knock-out seçenekleri) Önceden tanımlanmış engelleri ihlal edebilir ve yerleşim veya yeni esnaf üreten sona alabilirsiniz.
  • hedef Tetikleyiciler: Bir hedefe doğru birikir Aletleri (Böyle aralık tahakkukları veya hedef itfa forward gibi) Hedef ulaşıldığında sona alabilirsiniz.
  • Ticaret Novation: Novation özel bir süreçtir hangi ticaret karşı değişiklikleri. Gerçekte, Orijinal karşı başka birine ticaret veya seçenek satıyor. Ne zaman bir yenileme oluyor, Orijinal ticaret sonlandırılır ve yeni bir özel niteliklere sahip başlatılan.

Doğrulama ve İşleme

Bir ticaret ticaret platformu veritabanına rezervasyonu sonra, bu doğrulama ve günlük işlem bütün bir koro tetikler. Doğrulama işlemi Orta Office Ön Büro ticaret masaları ve kontrol üniteleri arasında bir-ve-fro dans, tüm ticaret platformu aracılığı ile. tüccarlar deneysel bazda ticaret ekleyebilirsiniz. Onlar ikna kez uygulanabilir bir ticaret olduğunu, Onlar bir teyit duruma itin, hazine kontrol ünitesi tarafından yakalandı edilecektir. Tüccarlar ticaret atmak için karar verirseniz, ticaret çöp yığını içinde biter (ama kalıcı olarak silinir asla). Kontrol birimi, tipik olarak, dört göz çalışır, Çift doğrulama modu. Onlar ticaret girişleri doğrulamak, 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, they are pushed back into a state that allows the traders to either amend it or discard it.

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. Üst düzey tüccarlar bu normal işleme yoluyla genç olanlardan bilgi damıtılmış ve uygun eylemleri olsun.
  • Orta Ofis düzenli sürecinde önemli bir rol oynar. Onlar hedef ve bariyer ihlallerini izlemek, oran tertibat ve opsiyon egzersizleri, nakit akışı nesil, ve diğer nakit esnaf yumurtlama. Onlar oluşturmak (ticaret platformu yardımıyla) Arka Ofis hareket için uygun muhasebe tetikler, yerleşim gerçekleştirmek için, ticaret onayı, dokümantasyon, arşiv vb.
  • Ürün Kontrol aktif bir günlük bazda P / L izlemek orta ofis içinde gömülü bir başka iş birimi, hassasiyetleri ve piyasa hareketlerine dayanarak hareketlerini açıklayan bir bakış açısıyla, ticaret faaliyetinin karlılık bağımsız bir hesaplama sağlayan. 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.) as well as VaR computation, 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.

Ticaret Başlangıç

Bir ticaret başlangıç ​​olayları iki kategoriye ayrılabilir. Ön ticaret faaliyetleri ilk ticaret rezervasyonu bile önce yer almak zorunda olanlardır. başına ticaret başlangıç ​​faaliyetleri her ticaret özgü olanlar.

Pre-trade activities

Ön ticaret faaliyetleri üzerinde yatılı ve onay yeni ürün ile ilgili. As we saw, in-house ticaret platformları çevik ve duyarlı olacak şekilde tasarlanmıştır. Prensip olarak, yeni bir ürün üzerinde bindik olmak için biraz zaman almalı. Ben çalıştı son sistem, Örneğin, birkaç dakika içinde yeni bir ürün fikri dağıtmak için tasarlanmıştır. Ancak bu tip sistemlerde mimarları insan unutmak eğiliminde, içinde yer proses ile ilgili ve kontrol elemanları. slayt Yukarıda görüldüğü gibi, Yeni bir ürün fikri veya yeni bir fiyatlandırma modelinin model kant çalışmaları veya Önbüro bir yapılandırıcı kaynaklanır. Ama bir üretim sistemi yakın bir yere gelmeden önce, fiyatlandırma modeli doğrulanması gerekiyor, tipik olarak, analitik ekibi Orta Ofis risk yönetimi grubu. Bir kez doğrulandı, Ürün haftalar ya da aylar sürebilir dolambaçlı bir onay sürecinden geçer, ve daha sonra resmi bir dağıtım işlemi, Yine haftalar ya da aylar sürebilir. Bu süreç tamamlandığında, ürün ticaret platformu ticaret kullanılabilir.

kullanılabilir, Ürün bir ticaret olarak örneği olabilir. Her ticaret örneği kendi doğrulama ve onay sürecinden geçer. ticaret isteği Önbüro satış veya yapılanma ekibi kaynaklanabilir. Onlar da terim levha ve diğer yasal belgeler hazırlayacak. Bu görevlerini tamamladıktan sonra, Bir ticaret ticaret platformu haline rezervasyonu.

Per-trade process

Bu başlangıç ​​olaylar ikinci slayt üzerinde tasvir edilmiştir. onay sürecinde önemli adımlardan biri kredi kontrolü. Daha önce açıklandığı gibi, the Kredi riski yönetimi Takım riskleri değerlendirmek için çeşitli araçlar kullanır. Onların onayı ile, ve ürünün piyasa fiyatı tüccarlar anlayışı ile, ticaret platformu mevcut bir ürünün veritabanında bir ticaret olur. Ve lifecycling eğlence başlıyor.