When a trade changes, the people who build reporting data and design trading systems decide where to record the change. The recorded data is also used to pass the change to other systems, and to reconcile records with counterparties.

How events change trade state

A lifecycle event during the life of a trade changes the trade's state. Here, the state of a trade means its terms, balances, and parties at a point in time, together with whether the trade is continuing or has ended. In the data that the Financial Services Agency (FSA) specifies for reporting, a change of terms keeps the trade going, while early termination or exercise ends it. In a novation or clearing, the original trade ends and a new trade is created1.

If the data does not record this change in a form that shows when it happened, through which event, and from what to what, you cannot trace the history. The same holds for the market as a whole. Before 2005, the credit default swap (CDS) market had no central record of trades, which made it hard to manage events such as quarterly payments2.

The business flow of exercise notices, confirmation, and settlement is covered in Lifecycle Event Processing.

Event types and how trade state changes

Data reported to a trade repository separates the "action type," which says what was done to the trade, from the "event type," which says why. In the FSA's guidelines on reporting items, the action types are the following nine: New, Modify, Correct, Error, Terminate, Revive, Transfer out, Valuation, and Collateral. The event types are the following 123.

Event type What it means Actions it can be combined with
Trade Creation or modification of a trade New, Modify
Novation A legal transfer of some or all of the risk of a trade from the transferor to the transferee. The original trade ends or is modified, and a new trade is created New, Modify, Terminate
Compression or Risk Reduction Exercise A set of existing trades is ended or modified, and a new trade is created New, Modify, Terminate
Early termination A trade is ended before its scheduled end date or maturity date Modify, Terminate
Clearing A central counterparty steps in between the parties and ends the existing trade between the seller and the buyer New, Terminate
Exercise All or part of the right in an option or swaption is exercised New, Modify, Terminate
Allocation An agent that traded for several clients allocates part of the trade to the clients New, Modify, Terminate
Clearing and Allocation Clearing at a central counterparty and allocation happen at the same time New, Terminate
Credit event An occurrence that changes the status of a credit derivative that has already been reported Modify, Terminate
Transfer A trade is moved to another trade repository New, Transfer out
Corporate event A corporate action on the underlying shares that affects an equity trade New, Modify, Terminate
Upgrade Outstanding trades are brought into line with revised reporting requirements Modify

The permitted combinations are those that Appended Table 5 of the guidelines allows. Data with a combination that is not in Table 5 may not be accepted4. For example, an option exercise is reported as the combination of the action Terminate and the event Exercise. The party whose option was exercised reports it the same way3.

None of the 12 event types corresponds to a rate fixing or an interest payment. The Terminate action is not used for a trade that ends on its contractual maturity date3. Even for a trade whose notional amount falls as scheduled, such as an amortizing swap, the steps in the notional schedule are not treated as events. The report gives the initial notional amount agreed when the trade started, and after a change or event it gives the resulting balance5.

Keeping the history before and after a change

Reporting data updates a trade under the same unique transaction identifier (UTI) for as long as it continues, and gives a new UTI when it is replaced by a different trade. When a trade is replaced one to one or one to many, the new trade carries the UTI of the previous trade as the Prior UTI, which keeps the link6. When several trades are replaced by one or more trades, the Prior UTI is not used7.

What happened UTI Link to the previous trade
A change of terms, a mark-to-market update, or early termination (including partial termination) The report is updated under the same UTI Not needed
Full novation The post-novation trade gets a new UTI The UTI of the original trade that ended is reported as the Prior UTI
Partial novation The UTI of the original trade does not change, and the trade remains. The post-novation trade gets a new UTI The UTI of the original trade is reported as the Prior UTI
Swaption exercise The underlying swap created by the exercise gets a new UTI The UTI of the new swaption trade is reported as the Prior UTI
Several trades replaced by another trade, as in compression A new UTI is assigned A Prior UTI cannot be used. The trades are linked by an event identifier
YesNoIs a new trade createdapart from the original?Update thereportunder the sameUTIYesNoAre the original and newtrades linked one to oneor one to many?Assign a newUTI.A Prior UTIcannot be usedAssign a new UTIand add thePrior UTI
Figure 1How to assign a UTI when a trade changes
Figure description

A change of terms or a mark-to-market update is reported under the same UTI. The details for cases such as partial termination, where the trade remains, are in the previous table.

Consider a hypothetical example in which the UTI of trade P is "A." After its terms are changed, the UTI is still A and the report is updated. If the trade is then transferred by a full novation, the post-novation trade gets a new UTI "B," and the UTI "A" of the original trade that ended is added as the Prior UTI. The history can be traced from A to B.

A Prior UTI can be used when trades are linked one to one or one to many (novation, exercise, clearing). It cannot be used when several trades lead to one or more trades (compression and the like). For compression and credit events, an event identifier is needed instead, to link the trades that result from the event. The reporting party or a service provider assigns it7.

The history also keeps the date and time of the event. The event time that is reported may be the time the event was entered into the system or the time the data was created, instead of the time the event actually occurred. If the system cannot record seconds, the seconds and below may be set to 00. For clearing, the reported time is when the central counterparty accepted the original trade and its system recorded it8.

Consider a hypothetical example in which a credit event reduces the notional amount of a CDS index trade built from 50 names, with a notional amount of 1 billion yen, or 20 million yen per name. A credit event occurs for one of the names and is settled. The trade continues, and the notional amount falls. The report gives the notional amount after settlement and the index factor, which is the notional amount after settlement divided by the notional amount before settlement (the share left after settlement)9.

Point in time Notional amount Index factor
New trade 1 billion yen 1.0
After settlement of a credit event for one name 980 million yen 0.98

Corrections and cancellations

Reporting treats a change of terms (Modify), a correction of an error (Correct), the cancellation of a whole trade (Error), and the restoration of a canceled or wrongly terminated trade (Revive) as separate actions3. Two points concern how the history is kept. When an error other than the UTI is corrected, the report is updated under the same UTI6. When a correction and a mark-to-market valuation happen on the same day, two lines are reported, a Correct and a Valuation3.

As for corrections and cancellations in internal systems, a 2010 operational guidance document for foreign exchange trades covers this. It is not a binding rule but an industry goal10. Input errors can occur in the counterparty, the value date, the rate, and so on, and a trade may be corrected or canceled after it has been passed to operations. The guidance says that the details of that procedure differ from one financial institution to another and are often set by system constraints11. With the counterparty, the party that made the error corrects the trade in its own system and issues a corrected confirmation12.

Passing data on, and state mismatches

Separately from reporting data, the CDM (Common Domain Model) is a data model in which each event creates the post-change trade state from the pre-change trade state, and the states are chained so that the path of a trade can be traced14. The structure of the CDM is covered in The ISDA Common Domain Model (CDM).

When the front office (sales and trading) and the back office (operations and settlement) use different systems, the 2010 operational guidance recommends passing trades, adjustments, and cancellations automatically from one to the other through an electronic link. Where possible, the same data is passed on as it is for posting to the general ledger, updating credit information, producing payment instructions for funds, and so on15. Re-entering trades into the back-office system can introduce errors, so passing them straight through is a way to reduce errors and get the data there sooner16.

Front officeBack officeA trade, adjustment,or cancellationoccursReceive it automaticallyover an electronic link,with no re-entryPass the same data tothe general ledger,credit data, payments
Figure 2Passing trades, adjustments, and cancellations from the front office to the back office
Figure description

The figure shows how data is passed when the front office and the back office use different systems. When a trade, adjustment, or cancellation occurs in the front office, it is passed automatically to the back-office system over an electronic link, and the back office does not re-enter it. The last step is positioned as something to do where possible.

In reporting data, updates to valuation and collateral are passed as separate actions (Valuation and Collateral), not as events3.

Three examples of the difficulties in keeping trade state aligned, and of ways to prepare for them:

  • Mismatched records with counterparties. A 2010 paper names, as a way to reduce disputes over collateral, regular reconciliation with the counterparty of whether the main economic terms of the derivatives and the collateral positions agree. Among the major dealers, an independent third party can also do the reconciliation and point out the trades that do not match17.
  • Mass changes of terms. Replacing the reference rate of yen LIBOR trades with an alternative benchmark required, beyond the contractual agreement between the parties, developing or changing the systems used for the trades and reviewing operational workflows. The number of trades was huge, and the review noted that neither reaching the agreements nor doing the work was easy (May 2022)18.
  • Checking the history in an audit. The February 1998 examination manual of the US Federal Reserve Board lists, as one of its examination objectives, confirming that automated systems and manual processes are designed with an audit trail sufficient to assess and ensure the accuracy of the data19.

Notes

  1. 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), item 101 "Action type" notes (page 26) and item 102 "Event type" (page 27) in Attachment 1, and Attachment 2, section 5 (1) (pages 6–7) (in Japanese). ↩

  2. Darrell Duffie, Ada Li, and Theo Lubke, "Policy Perspectives on OTC Derivatives Market Infrastructure" (Federal Reserve Bank of New York Staff Report no. 424, 2010), the first item in Table 1 (page 3). ↩

  3. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), item 101 "Action type" (page 26) and item 102 "Event type" (page 27) in Attachment 1; pages 30 and 31 of the PDF. The "What it means" column of the table summarizes the definitions under item 102 (in Japanese). ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), Appended Table 5 "アクションタイプ・イベントタイプの組み合わせ" (Combinations of action types and event types) (page 44); page 47 of the PDF. The "Actions it can be combined with" column of the table reads the checks in this appended table row by row (in Japanese). ↩

  5. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), item 87 "Notional amount" in Attachment 1 (page 23); page 27 of the PDF (in Japanese). ↩

  6. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), Attachment 2, section 5 (1) (pages 6–7), and its footnotes 8 to 10; pages 54–55 of the PDF (in Japanese). ↩ ↩2

  7. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), item 26 "Prior UTI" (page 9) and item 103 "Event identifier" (page 27) in Attachment 1; pages 13 and 31 of the PDF (in Japanese). ↩ ↩2

  8. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), item 104 "Event timestamp" in Attachment 1 (page 27); page 31 of the PDF (in Japanese). ↩

  9. Financial Services Agency, "店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン" (December 2022), the reference example under item 105 "Index factor" in Attachment 1 (page 28), reworded with the figures unchanged (notional amount of 1 billion yen, 20 million yen per name, 980 million yen after settlement); page 32 of the PDF (in Japanese). ↩

  10. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), the introduction (page 6). ↩

  11. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), Best Practice no. 11, "Review Amendments" (page 18). ↩

  12. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), "Process Description" in the "Confirmation" section (page 21, between Best Practice no. 12 and no. 13). ↩

  13. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), the last paragraph of Best Practice no. 11, "Review Amendments" (page 18). ↩

  14. FINOS, "Common Domain Model," the "Event Model" page (version 7.0.0), the "Trade State" and "State" sections. ↩

  15. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), Best Practice no. 7, "Use Straight-Through Processing" (page 15). ↩

  16. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), Best Practice no. 7 (page 16). ↩

  17. Darrell Duffie, Ada Li, and Theo Lubke, "Policy Perspectives on OTC Derivatives Market Infrastructure" (Federal Reserve Bank of New York Staff Report no. 424, 2010), page 19. ↩

  18. Bank of Japan Financial Markets Department and Financial System and Bank Examination Department, and Financial Services Agency Strategy Development and Management Bureau and Supervision Bureau, "円LIBOR移行対応の振り返りと今後の取り組み" (Bank of Japan Review 2022-J-8, May 2022, in Japanese), page 2. An English version is available: "Review of JPY LIBOR Transition and Future Initiatives" (Bank of Japan Review 2022-E-4, May 2022). The page number refers to the Japanese version. ↩

  19. Board of Governors of the Federal Reserve System, "Trading and Capital-Markets Activities Manual," Section 2040.2 "Examination Objectives" (February 1998), item 7. ↩

  20. The Foreign Exchange Committee, "Management of Operational Risk in Foreign Exchange" (November 2004, revised November 2010), Best Practice no. 24, "Establish Exception Processing and Escalation Procedures" (page 27). ↩