A trade that has been executed passes through the systems of several departments for entry, confirmation, settlement, posting and reporting. The back office, which takes the front office's entry through confirmation and settlement, and the middle office, which checks market values and risk on the same data, use these systems in their daily work.

Systems divided by function

According to the US Federal Reserve's examination manual, around 1998 the systems of a financial institution dealing in derivatives were often a combination of systems for different functions. The functions they support include managing market risk and credit risk, processing transactions, settlement, accounting, and financial, regulatory and management reporting1. Their users also span several departments: senior management, risk management, the front office (sales and trading), the back office (operations and settlement), financial reporting and internal audit. The main systems and what each handles are as follows.

System Main responsibilities Main departments involved
Trading system Entering trade terms, recording positions, checking market values during the day Front office
Risk management system Calculating market values and risk measures, monitoring risk limits, reporting to senior management Middle office (risk management and others)
Confirmation, settlement and collateral system Sending and receiving trade confirmations, issuing payment instructions, valuing and exchanging collateral Back office (confirmations and payment instructions)
Accounting system Posting to the general ledger (the book that brings all accounts together) Back office (supplies the confirmed trade records that postings are based on)

The trading system records the basic details of a trade, such as the trade date and time, settlement date, counterparty, instrument, amount, and price or rate2. Around 2003, financial institutions that used collateral to manage credit risk typically had a collateral management system for valuing and monitoring collateral3. Postings to the general ledger and payment instructions at maturity are based on the confirmed trade records4.

The roles of each department, including those that handle collateral and posting to the general ledger, and the reasons for separating departments are covered in Front, Middle and Back Office Roles.

Data flow from trade execution to settlement and accounting

Trade data is created at trade capture and then used in turn for confirmation, settlement and posting to the ledger. Consider a hypothetical example in which a financial institution executes a 5-year interest rate swap with a notional amount of 10 billion yen with a counterparty. Figure 1 shows which systems the data for this one trade passes through.

TradingConfirm & settleAccountingFront officeenters thetrade termsBack officeverifies andacceptsConfirmationmatched withcounterpartyCash paid andreceived onpayment dateGeneral ledgerupdated
Figure 1Data flow from trade entry to the general ledger
Figure description

The figure shows the order in which the data for one interest rate swap passes through three systems: trading; confirmation, settlement and collateral; and accounting. It shows the case where automated processing systems are used. First, the front office enters the trade terms into the trading system, and the back office verifies them before accepting the trade. The accepted trade data passes to the confirmation, settlement and collateral system, where the back office matches the confirmation with the counterparty. For a matched trade, cash is paid and received on the payment date, and the result updates the general ledger in the accounting system. The risk management system also uses the same trade data.

Around 1998, the back office verified the front office's input before accepting it where straight-through processing (STP) or other automated processing systems were used5. STP cuts manual work and handles trades as one continuous process. The back office sends a confirmation to the counterparty and compares it with the counterparty's confirmation. Confirmations can also be generated automatically from an online trading system6.

On the payment date (settlement date), cash or other assets are paid and received, and the general ledger postings are updated at the same time7. The payment and receipt procedures are covered in Settlement. Recorded trades are revalued periodically and removed from the books when they end through maturity, sale, termination, exercise or other events4. Processing such as rate fixings and exercise also occurs during the life of a trade.

Records held in different systems are reconciled periodically. The items reconciled include traders' position reports against the general ledger, the general ledger against regulatory reports, and brokers' trade statements against the general ledger. The staff who perform reconciliations are kept independent of the staff who enter trade data8.

Keeping market data and trade reference data consistent

Market data are the values used in calculating market values and risk measures, such as interest rates, exchange rates, prices and volatilities. If the front and back offices use different valuation assumptions or methods, financial reporting and the assessment of market risk may be wrong10.

Sources of market data include prices published by exchanges and prices distributed by information services for actively traded over-the-counter instruments. Exchange prices can be used to check, independently of trading, the values that traders have assigned. On the other hand, for thinly traded over-the-counter instruments, especially complex OTC derivatives, fewer market prices are available for such checks10.

Keeping counterparty and trade data in a single database makes its accuracy easier to maintain than gathering it from multiple sources. When multiple databases are used, the data is reconciled at each point where data from different sources is brought together9.

Intraday processing and end-of-day processing

Some system processing happens trade by trade as it occurs, and some handles the day's trades together. An example of trade-by-trade processing is the check before execution. Before agreeing to a trade, a trader checks that it falls within the counterparty's credit limit and the approved trading limits2. Systems can support this check.

Separately from trade-by-trade processing, market values and risks are checked and reported at set frequencies. In practice around 1998, market values were determined both intraday and daily. Traders determined them during the day to monitor their own positions, and control staff determined them daily to assess the impact on earnings12. The examination manual also sets how often risk is reported. Position risks and P&L are reported at least daily to managers who supervise trading13. In businesses with heavy trading activity, risk management can see exposures during the day as well14.

End-of-day batch processing runs the day's trades together. Japan's Financial Services Agency (FSA) Comprehensive Guidelines for Supervision of Major Banks, etc. require banks, when preparing plans for system failures and similar events (contingency plans), to also assume cases such as a major delay in batch processing15.

Connections with outside bodies

A financial institution's systems do not stay closed within the firm. They exchange data with matching platforms, central counterparties (CCPs), payment systems and trade repositories. The role of each and what is exchanged with it are as follows.

Outside body Role What the financial institution exchanges with it
Matching platform Lets both parties to a trade match the trade terms Trade terms, matching results, clearing requests
Central counterparty Steps in between the parties to a trade and guarantees settlement Clearing requests, clearing status, margin reports
Payment system Transfers funds between participants Payments and receipts of funds
Trade repository Collects and maintains records of trade data Reports of trade information

MarkitSERV's 2012 response states that other providers also offer similar matching services17.

A central counterparty steps in between the parties to a trade, becoming the buyer to every seller and the seller to every buyer, and guarantees settlement18. For interest rate swaps at Japan Securities Clearing Corporation (JSCC), both parties match the trade on a matching platform or a trade execution platform and apply for clearing. JSCC checks whether the trade meets the conditions for clearing and whether enough collateral has been posted, assumes the obligations, and then distributes reports on the status and on margin and other items19.

A payment system is a set of instruments, procedures and rules for transferring funds between participants20. A trade repository is an entity that collects and maintains electronic records of trade data, used especially in OTC derivatives markets21.

In Japan, for certain OTC derivatives transactions, financial instruments business operators, etc. and central counterparties provide trade information to trade repositories22. The reported items include, besides the trade terms, the valuation of the contract and the amounts of initial margin and variation margin23.

Reporting also uses the Legal Entity Identifier (LEI), which identifies the parties to a trade, and the Unique Transaction Identifier (UTI), which identifies each individual trade24.

STP: cutting manual work to process trades in one continuous flow

STP (straight-through processing) means linking systems automatically through messages in a standard format so that the processing from execution to settlement runs as one continuous process without manual intervention25. In practice around 1998, when the front and back offices used separate systems to enter trades, the trader handwrote a trade ticket and delivered it to the back office, which used it as the basis for its own input. Even where STP or other automated processing systems were used, the back office verified the front office's input before accepting it5.

In securities trading around 1999, the front, middle and back office stages had each been automated separately, with different formats and systems at each stage, so trade details were often re-entered by hand at the boundaries between stages26. STP removes this manual re-entry and reduces the risk of input errors and data tampering. On the other hand, trades that several departments used to process separately come to be processed from the input of fewer departments, so checks on input authority and records that let processing be traced afterward (audit trails) are needed separately27.

Linking systems automatically requires a common data format. For OTC derivatives, FpML is an XML standard for exchanging and processing trade information electronically28. The trade reporting guidelines also map the reportable values for the day count convention to the codes of ISO 20022 (the international standard for financial messaging), FIX (a messaging protocol used mainly in securities trading) and FpML29.

One integrated system or several

Whether systems are combined into one or divided by function varies between financial institutions. Around 1998, according to the examination manual, it was rare for a single system to handle everything from data entry through all processing and controls for every over-the-counter and exchange-traded instrument, and institutions sometimes combined systems bought from vendors with systems built in-house9. Not all systems are necessarily linked into one whole, and manual steps may come in between. The examination manual asks examiners to check whether data integrity is maintained at the manual steps1.

One reason for the difference is trading volume. At an institution with little trading, automating risk management reporting may not be worth the cost, and much of the analysis can be done by hand. As trading grows and manual work can no longer keep up with risk monitoring, automation may become worthwhile9. Whatever the arrangement, the institution documents the flow of data from input to reporting in flowcharts or narratives9.

When systems are divided and linked, the way data is represented has to be made consistent across systems and firms. Besides FpML, efforts toward this include the CDM (Common Domain Model). The CDM is a standard model that represents financial products, trades in those products, and the lifecycle events of those trades in a machine-readable and machine-executable form30.

Notes

  1. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2040.1 "Operations and Systems Risk (Management Information Systems)" (February 1998), pages 1–2. ↩ ↩2

  2. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2050.1 "Front-Office Operations" (February 1998), pages 2–3. ↩ ↩2

  3. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2020.1 "Counterparty Credit Risk and Presettlement Risk" (April 2003), page 14. ↩

  4. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 "Operations and Systems Risk (Back-Office Operations)" (February 1998), page 3. ↩ ↩2

  5. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2050.1 (February 1998), page 2, "Transaction Flow." ↩ ↩2

  6. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 (February 1998), page 3, "Confirmations." ↩

  7. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 (February 1998), page 4, "Settlement Process." ↩

  8. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 (February 1998), page 5, "Reconciliations." ↩

  9. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2040.1 (February 1998), page 2 (continuation of "COMPUTING SYSTEMS"). ↩ ↩2 ↩3 ↩4 ↩5

  10. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 (February 1998), page 6. ↩ ↩2

  11. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2040.1 (April 2003), page 3, "Parameter Selection and Review." ↩

  12. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2060.1 (February 1998), page 6. ↩

  13. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2040.1 (February 1998), page 1. ↩

  14. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2000.1 "Overview of Risk Management in Trading Activities" (February 1998), page 6. ↩

  15. Financial Services Agency, "主要行等向けの総合的な監督指針" (Comprehensive Guidelines for Supervision of Major Banks, etc.) (October 2026), III-3-7-1-2(9)③ (page 267) (in Japanese). ↩

  16. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2020.1 (April 2003), page 14 (intraday credit exposure, and passing data from the collateral management system to the credit limit system). ↩

  17. MarkitSERV's response to the European Securities and Markets Authority (August 5, 2012), "offered also by various other providers." ↩

  18. Committee on Payment and Settlement Systems of the BIS and Technical Committee of the International Organization of Securities Commissions, "金融市場インフラのための原則" (Principles for financial market infrastructures, provisional Japanese translation; April 2012), paragraph 1.13 (pages 11–12) (in Japanese). The English original is CPSS-IOSCO, "Principles for financial market infrastructures" (April 2012), which uses the same paragraph numbers. ↩

  19. Japan Securities Clearing Corporation, "金利スワップ 債務負担" (in Japanese), "債務負担のワークフロー・イメージ" (Workflow of assumption of obligations). An English version is available: "IRS Clearing", "Illustration of Clearing Workflow". ↩

  20. "金融市場インフラのための原則" (Principles for financial market infrastructures, provisional Japanese translation), paragraph 1.10 (page 10) (in Japanese). The English original uses the same paragraph numbers. ↩

  21. "金融市場インフラのための原則" (Principles for financial market infrastructures, provisional Japanese translation), paragraph 1.14 (page 12) (in Japanese). Box 1 (page 13) lists confirmation and matching platforms among the stakeholders of trade repositories. The English original uses the same paragraph and box numbers. ↩

  22. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (Guidelines on the items to be prepared, retained, and reported under Article 4, paragraph 1 of the Cabinet Office Order on the regulation of OTC derivatives transactions, our translation) (December 2022; "the guidelines"), page 1 (in Japanese). The guidelines cite as their basis Articles 156-63 and 156-64 of the "金融商品取引法" (Financial Instruments and Exchange Act, in Japanese; English translation: Japanese Law Translation). ↩

  23. Financial Services Agency, the guidelines (December 2022), "報告事項 一覧" (List of reporting items): valuation, item 39; initial margin, items 45–49; variation margin, item 51 (in Japanese). ↩

  24. Financial Services Agency, the guidelines (December 2022), page 1 (the UTI in Attachment 2) and "報告事項 一覧" (List of reporting items), item 9 (whether the identifier of counterparty 2 is an LEI) (in Japanese). ↩

  25. 宮田慶一, "証券取引のSTP化を巡る動きについて" (Developments toward STP in securities trading), Bank of Japan, "日本銀行調査月報" (October 1999), pages 1–2 (in Japanese). The paper defines STP for securities trading. ↩

  26. 宮田慶一, "証券取引のSTP化を巡る動きについて" (October 1999), page 5 (in Japanese). ↩

  27. 宮田慶一, "証券取引のSTP化を巡る動きについて" (October 1999), page 7 (in Japanese). ↩

  28. TC68 国内委員会事務局 (secretariat of the Japanese national committee for ISO/TC 68, Institute for Monetary and Economic Studies, Bank of Japan), "ISO 20022 の概要" (Overview of ISO 20022) (March 2015), page 6, footnote 13 (in Japanese). The document describes FpML as an open-source standard developed under the sponsorship of the International Swaps and Derivatives Association (ISDA). ↩

  29. Financial Services Agency, the guidelines (December 2022), Appended Table 1, "Day count convention" (in Japanese). The descriptions of ISO 20022 and FIX are from "ISO 20022 の概要" (March 2015), page 1 and footnote 14 on page 6 (in Japanese). ↩

  30. FINOS, "Common Domain Model," introductory description. ↩