Price Scrubbing UI Example & Trade Ticket Golden Copy Lifecycle<br />By Shaun James Siddells in response to a competency q...
Question 1: Provide a mock-up of a screen with description to describe the functionality a data operator would need to res...
Fig 2. UI Prototype<br />The basics of any screen revolves around the most important information & functions being at the ...
Question 2: Describe in detail what a golden copy is and how it is generated, validated (incl sample rules) and managed. A...
Trade details Incl. Trade Reference Number
of 5

Price Scrubbing & Golden Copies (Info Only)

Requested competency notes on basic UI requirements for Prices Scrubbing & a demonstrations of the Life of a Golden Copy
Published on: Mar 4, 2016
Source: www.slideshare.net


Transcripts - Price Scrubbing & Golden Copies (Info Only)

  • 1. Price Scrubbing UI Example & Trade Ticket Golden Copy Lifecycle<br />By Shaun James Siddells in response to a competency query.<br /> I was asked to respond to a few questions <br />Which apparently hit the nail the head with what the client was after in regards to a particular price scrubbing screen, & also in the definition & lifecycle of a Golden Copy for Trade Tickets<br />I have posted these as a matter of interest in the process of Market Feed Consolidations & Golden Copy Generation as it relates to the Trade Processing Lifecycle.<br />These notes are to be considered for informational usage only & have compiled from various sources including my own work & should not be thought of in any other context.<br />
  • 2. Question 1: Provide a mock-up of a screen with description to describe the functionality a data operator would need to resolve a price scrubbing exception in an environment which contains multiple sources of data. (1-2 page response expected).<br />Before any screen can be “mocked-up” a basic understanding of the relevant lifecycle needs to be clear. As this was not provided, some initial investigation, assumptions & logic were applied to establish a quasi-lifecycle/flow from which a reference to the requested screen can be established. This lifecycle is described below & like the following screenshots, it hopes to elaborate more than has been documented.<br />Fig 1. Market Feed Consolidation Lifecycle<br />Basically we’re talking about a Market data feed consolidator (an aggregator of market feeds) which finds an exception for a “data operator” to amend before publication of some indicative price - for a particular asset (class). The screen layout & functions would depend on many things, & what is provided over-leaf is indicative to my current understanding of the question<br />
  • 3. Fig 2. UI Prototype<br />The basics of any screen revolves around the most important information & functions being at the top of the screen, easy to see & access, with as much supporting information & features available peripherally without cluttering the screen (or through scrolling) - which enables & empowers (or constrains) the user as necessarily required<br />
  • 4. Question 2: Describe in detail what a golden copy is and how it is generated, validated (incl sample rules) and managed. Also provide examples of business domain usages for a golden copy. (1-2 page response expected, diagrams optional)”<br />Generic Definition: <br />The ‘golden copy’ is the official, master version of a record. There can only be one golden copy of each record. A golden copy exists from the point of creation of a record not just once the record is no longer used. It is important to remember that the golden copy of a record exists for all stages of its development<br />The concept of the "golden copy" of reference data involves creating a trusted set of data for all aspects of the STP process within one organisation potentially from various data feeds. A trusted golden copy is necessary because STP depends not on one single application but a series of applications (See Fig 3. trade Processing Lifecycle), each of which requires access to instrument, settlement, routing, trade, counterparty and other types of data. Regulatory reporting & compliance rulings such as that driven by the Dodd-Franks Act, Solvency II, Basel II (& III) & anti-money laundering rules are greatly compounding & extending “Golden Copy” content requirements… Such is the nature of OTC based derivatives.<br />In regards to my experience with Dodd-Frank Act: A golden copy is an industry term for the copy of the ‘trade of record’ to be reported on to regulators and as a fall back in case of dispute or litigious recourse. It is typically the copy or version of the trade which also settles.<br />A copy of the golden copy may be required by either a 3rd Party (compliance), front, middle or back office personnel, regulators, external & internal auditors.<br />Golden copies are generated at trade capture & are maintained until a copy is securely deposited in the appropriate trade repository after settlement, & also after it is deposited in the newly formed 3rd party trade reporting/repository <br />(See Fig 4. CCP & Compliance Repositories)<br />Golden copies are validated through the front, middle & back office – pretty much at any exit & entry point in the trade & systems lifecycle of a trade. (See Fig 3. Trade Processing Lifecycle). Trade are validated automatically &/or manual based on specified rules. Trade Validated Rules might include ensuring the following are correct:<br /><ul><li>Trading & Counterparty details
  • 5. Trade details Incl. Trade Reference Number
  • 6. Enrichment & Settlement details
  • 7. Figuration details
  • 8. Trade Date& Value date
  • 9. Field data types (Numerical values)
  • 10. Trade above minimum specified trade thresholds
  • 11. Trade Type correct for trading counterparties
  • 12. Contract Terms & Conditions
  • 13. Negotiated rates
  • 14. Principle values or notionals
  • 15. Settlement details(Basic – location etc)
  • 16. Fees & Charges
  • 17. Commission Charges & Accrued Interest
  • 18. Record duplication</li></ul>As well as checking:<br /><ul><li>Any other anomalies
  • 19. Missing data
  • 20. Inaccurate data (Product descriptions etc)
  • 21. Unrealistic Numerical values
  • 22. Other Trade Rules - specific to a counterparty</li></ul>Basic data validation principles also apply (as noted by the various sources):<br /><ul><li>Accuracy - a consensus that the data is correct
  • 23. Completeness - data values present meet the specific requirements
  • 24. Consistency - the data is free from variations
  • 25. Uniqueness - data recorded is represented in a special way like a primary key or trade reference
  • 26. Timeliness - data values and records are up to date
  • 27. Validity - the quality of inputted data meets the requirements for accurate identification</li></ul>Note: This assumes my assumption that golden copy is specifically regarding the new compliance requirements for OTC Derivatives.<br />
  • 28. Rules should be housed & managed in a Rules Engine or Rules Repository for easy configuration (Note: I have previously worked on validations rules engines)<br />The rules engine should hold or reference static & market data as well as field level logic, trade comparison logic, & various other data & trade usage/execution rules. These can be configured on a trader-to-trade arrangement, trading party-to-asset class, asset class-to-counterparty; & trade threshold-to-trader basis to name a few.<br />The combinations are many, but be can succinctly categorised to ensure easy readability & configurability (using such concept as decision management),be owned by the business, & managed by the appropriate administrator. Rules can also be managed in an MSA (Master Reference Article) & a copy supplied to the developers if a management tool is not feasible or available.<br />Fig 3. Trade Processing Lifecycle<br />Fig 4. CCP & Compliance Repositories<br />This diagram shows the flow of a trade ticket from generation to repository (proposed in affect of the Dodd-Frank Act).<br />

Related Documents