The future of
financial
standards
London, 25 March
#SISF
Welcome
Gottfried
Leibbrandt,
SWIFT Professor
George Gaskell,
The London School of
Economics
and Political
Science
#SISF
The Future of Financial Standards
Gottfried Leibbrandt
25 March 2014
Keynote
speech
Commissioner
O’Malia
Commodity Futures
Trading Commission
(CFTC)
#SISF
www.cftc.gov/PressRoom/SpeechesTesti...
Suzanne
Morsfield,
Columbia
Business
School
#SISF
A critical
and empirical
examination of four
currently used
financial da...
* “A critical and empirical examination of
currently-used financial data collection
processes and standards”
– Initial Mod...
*Suzanne Morsfield, CEASA at Columbia University
*Steven Yang, Stevens Institute
*Susan Yount, formerly of the US SEC
*Tha...
*“We can't find the "London Whale…”
14
*Standards/Settings:
*ISO20022
*FIX
*XBRL
*SDRs/TRs
*Stakeholders:
*Regulators
*Designers
*Filers/preparers
*End users
15
*Standards/Settings:
*ISO20022
*FIX
*XBRL
*SDRs/TRs
*Stakeholders:
*Regulators
*Designers
*Filers/preparers
*End users
Big...
*What processes/designs around data
collection/standards would help us all find
the London Whales in our own (big) data?
17
*For a given standard:
*Several possible decision levels:
*Policy-related issues
*Technology-related issues
*Business-rela...
*A common model across all stakeholders and
contexts:
*By which to evaluate/change existing standards
*By which to decide ...
*A detailed understanding from all
stakeholders and contexts of the business-
related issues):
*About the process by which...
21
Initial
Model
Identify
Participant
Pool
Initial
Research,
Interviews
& Surveys
Initial
Statistics
Conference
Presentation
...
Core Areas
Big Data Issues
Terminology
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. Le...
Core Areas
Big Data Issues
Terminology
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. Le...
Core Areas
Big Data Issues
Terminology
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. Le...
Core Areas
Big Data Issues
Terminology
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. Le...
Terminology Dictionaries Communication
Standards
Reference Modeling Relationship Modeling
Common
Terms
&
Their
Definitions...
Core Areas
Big Data Issues
Terminology &
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. ...
Core Areas
Big Data Issues
Terminology &
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. ...
Core Areas
Big Data Issues
Terminology &
Dictionaries
Communication
Standards
Reference
Modeling
Relationship
Modeling
1. ...
Stakeholders Standard Setters Filers/Preparers End Users
Big Data Issues
1. Leveraging the standard External technology
an...
32
*Views on Big Data
*The 3 Vs and if BD even applies…
*Entity Identifiers and LEI
*Product Identifiers and UPI
*Software to...
* “Overly complex XBRL standard which is implemented
inconsistently across the user base. Differences in GAAP/IFRS
standar...
*Views on Big Data
*The 3 Vs and if BD even applies…
*Entity Identifiers and LEI
*Product Identifiers and UPI
*Software to...
*Filers will do what they are asked, and no more
*Compliance does not = success
*Regulators’/Designers’ willingness to
ada...
*
“Market standards must meet the
following challenges to promote and
maintain industry-wide adoption.
They must:
• Fulfil...
*
*“[Relational databases] could be the biggest
impediment to progress. It’s not that we don’t
need them, it’s just not wh...
*Where does a particular data/standard issue fit
right now?
*Where will it fit in a year, 3 years, 5 years, 10
years?
39
*Questions?
*Comments?
*Input?
40
41
#SISF
Common
financial
language
Academic research
presentation
Alistair
Milne,
Loughborough
University School of
Business ...
THE PROSPECTS FOR COMMON
FINANCIAL LANGUAGE IN
WHOLESALE FINANCIAL SERVICES
Swift Institute Working Paper
Alistair Milne (...
The proposition
• A universal language for finance
“LEIs (global legal entity identifiers) the ‘nouns’ of a common
financi...
Our findings
• A single common language is not realistic
• Movement towards a common financial
language will be useful for...
Three arguments why ...
1. Theory: Philosophical perspectives
– No single, unchanging, underlying financial reality
– Plat...
Figure 1: relational database design is
a constraint
Loan Portfolio Table
Loan Portfolio Identifier (Key)
Loan Portfolio N...
Database CFL
Database CFL
Semantic
Adapter
Direct
Correspondence
between CFL and
Database
Correspondance
between CFL and
D...
Our findings again
• A single common language is not realistic
• Movement towards a common financial
language will be usef...
• Swift Institute Working Paper
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2325362
• Alistair Milne
a.k.l.milne@lb...
Macroprudential
oversight,
risk communication
and
visualization
#SISF
Peter Sarlin,
Goethe University
Frankfurt
Presentations
#SISF
The
future of
standards
Coffee
break
Panel
sessions
Stuart
Weinstein,
Coventry Law
School
#SISF
The
future of
standards
Andrei
Kirilienko,
MIT Sloan School
of Management
Professor Stuart Weinstein
Coventry Law School
Faculty of Business Environment and Society
25 March 2014 – Future of Stand...
Academic Problem Statement
• The famous quote that ‘England and America are two
countries separated by a common language’ ...
The regulatory puzzle
• No one doubts that coordination of OTC derivatives
market is necessary to reduce systemic risk, im...
Different solutions – different
outcomes?
• Legal systems and market conditions differ among
jurisdictions necessitating d...
There are distinctions but not
fundamental core differences.
• The differences, however, are for the most part not
signifi...
Different Reporting Requirements
• In the area of swap data reporting, there are
differences in timing – in the US ranging...
Clearing and Swap Processing
• Standardised OTC derivatives will be centrally
cleared by well-regulated entities to reduce...
Clearing and Swap Processing
• Collateral Segregation: Omnibus segregation
approach in the EU. Individual segregation, how...
Clearing and Swap Processing
• Inter-affiliate Scope for Exemption: Exists in the
US for the exchange of initial margin (I...
Mandatory Trade Execution
• In the US, for Available to Trade if the trade is
standardised and ‘clearable’ it must be trad...
Portfolio Conciliation and Compression -
Disputes
In the US, financial counterparties must report disputes
that are unreso...
Trade Confirmation
• In the EU, both counterparties must confirm all trade
terms while in the US this obligations falls on...
Daily Trading Records
• The US wants records of the cash and forward
transactions to hedge swaps kept and trade
reconstruc...
External Business
Conduct Standards
• Transactions with US counterparties must comply
with all CFTC requirements including...
Law of Unintended Consequences –
US “Shadow Banking”
• Overlapping regulation for the banking & derivatives
markets means ...
Law of Unintended Consequences –
US “Shadow Banking”
• While it is unknown how much collateral will be
needed, much of it ...
EU – Vertical Silos to Collapse?
• European regulators are considering rules that may
require clearing houses to be intero...
Conclusions
• While the two regimes deliver broadly the same
outcomes in respect of the key regulatory goals, the
devil is...
Thank You.
Stuart.Weinstein@coventry.ac.uk
Implementing Financial Regulations:
What’s lost in translation? What can we do about it?
Andrei Kirilenko
MIT Sloan
Implementing Regulations: A CIO Perspective
From an e-mal to me:
“I have now been at [ ] for over a year and have seen us ...
Lost in Translation
Modern financial markets are complex adaptive systems of computer
algorithms. Yet, the regulatory fram...
Framework: Type I and Type II Errors
There are two types of implementation errors.
Type I (false positive) implementation ...
Type I and Type II Errors: A Reminder
Type I and Type II Errors: Costs and Efficiency
Each error is costly.
Type I error (doing what’s not needed) results in
ex...
Loss of Regulatory Efficiency
What can be done?: Go from Analog to Digital!
Each regulation is a circuit: it allows some things, prohibits
others and is...
Solution: TID Section in Each Regulation
To enhance regulatory efficiency, regulations written for
automated financial mar...
Boolean Algebra (0’s and 1’s)
Circuit Architecture: Inputs and Outputs
TID Section Should Offer Safe Harbor
The TID section would be akin to the cost-benefit analysis
(CBA) section currently re...
Envisioned Harvard-MIT Experiment
1. Create several HLS-MIT CS implementation teams. Have HLS students read an
existing (s...
Financial Regulation 1.0
clearing
commission
swaps
dco
customer
cleared
risk
margin
dcosmembers
derivatives
sec
member
pro...
Financial Regulation 2.0
Systems-Engineered. Regulate automated markets as complex systems
composed of software, hardware,...
#SISF
Panel
Lindsay
Thomas,
former
FSA
Brendan
Reilly,
Barclays
John
Trundle,
Euroclear UK
and Ireland
Emma
Kalliomaki,
AN...
#SISF
Panel
Marcus
Treacher,
HSBC
Marc
Bayle,
ECB
Chiara
Von Gunten,
UK Think tank
Z/Yen
James
Whittle,
RMG
ISO 20022
Step...
#SISF
#SISF
Andrew Muir,
SWIFT
Virginie
O’Shea,
AITE Group
Gert Raeves,
TowerGroup
Wrap-up
and
Closing
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
The Future of Financial Standards
Upcoming SlideShare
Loading in …5
×

The Future of Financial Standards

987
-1

Published on

The Future of Financial Standards

Event organised by the London School of Economics, the Standards Forum and the SWIFT Institute

London, 25 March 2014

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
987
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
46
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Future of Financial Standards

  1. 1. The future of financial standards London, 25 March #SISF
  2. 2. Welcome Gottfried Leibbrandt, SWIFT Professor George Gaskell, The London School of Economics and Political Science #SISF
  3. 3. The Future of Financial Standards Gottfried Leibbrandt 25 March 2014
  4. 4. Keynote speech Commissioner O’Malia Commodity Futures Trading Commission (CFTC) #SISF www.cftc.gov/PressRoom/SpeechesTestimony/ opaomalia-34
  5. 5. Suzanne Morsfield, Columbia Business School #SISF A critical and empirical examination of four currently used financial data collection processes and standards Steve Yang, Stevens Institute of TechnologySusan Yount, WebFilings LLC Academic research presentation
  6. 6. * “A critical and empirical examination of currently-used financial data collection processes and standards” – Initial Model & Pilot Study Results for SWIFT INSTITUTE WORKING PAPER NO. 2013-006 *
  7. 7. *Suzanne Morsfield, CEASA at Columbia University *Steven Yang, Stevens Institute *Susan Yount, formerly of the US SEC *Thank you to the SWIFT Institute for their support and invitation to present. 13
  8. 8. *“We can't find the "London Whale…” 14
  9. 9. *Standards/Settings: *ISO20022 *FIX *XBRL *SDRs/TRs *Stakeholders: *Regulators *Designers *Filers/preparers *End users 15
  10. 10. *Standards/Settings: *ISO20022 *FIX *XBRL *SDRs/TRs *Stakeholders: *Regulators *Designers *Filers/preparers *End users Big Data Issues & Solutions 16
  11. 11. *What processes/designs around data collection/standards would help us all find the London Whales in our own (big) data? 17
  12. 12. *For a given standard: *Several possible decision levels: *Policy-related issues *Technology-related issues *Business-related issues *Our focus is on the Business-related issues and so we look at the following: *Standard’s design, purpose, and evolution? *Filers/Preparers’ ability to input high quality data? *Users’ actual vs. perceived use? *Regulators’ monitoring and oversight needs met? 18
  13. 13. *A common model across all stakeholders and contexts: *By which to evaluate/change existing standards *By which to decide whether a new standard is necessary, and *By which to design a new standard that serves all stakeholders *At the Business-related issues level…. 19
  14. 14. *A detailed understanding from all stakeholders and contexts of the business- related issues): *About the process by which the standard or data collection process was designed and is maintained or updated *About the experiences of filers/preparers and end users (incl regulators) when complying with or consuming the output of the standard or process *About the methods for gathering input and providing an effective feedback loop 20
  15. 15. 21
  16. 16. Initial Model Identify Participant Pool Initial Research, Interviews & Surveys Initial Statistics Conference Presentation Feedback Loop Final Interviews, Surveys, & Statistics Test Model with New Standard or Setting Report w Final Model & Recommendations (& Statistics) 22
  17. 17. Core Areas Big Data Issues Terminology Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard 2. Identifying common obstacles 3. Implementing ongoing development & evolution Standard Regulators Designers SMEs Filers Preparers End Users 23
  18. 18. Core Areas Big Data Issues Terminology Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard 2. Identifying common obstacles 3. Implementing ongoing development & evolution IS020022 FIX XBRL SDRs/TRs 24
  19. 19. Core Areas Big Data Issues Terminology Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard 2. Identifying common obstacles 3. Implementing ongoing development & evolution 25
  20. 20. Core Areas Big Data Issues Terminology Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard 2. Identifying common obstacles 3. Implementing ongoing development & evolution 26
  21. 21. Terminology Dictionaries Communication Standards Reference Modeling Relationship Modeling Common Terms & Their Definitions in the Knowledge (Domain) Technology for Communicating Information & Knowledge Architecture for Capturing All the Domain Knowledge Hierarchy and Relationships in the Domain Knowledge 16
  22. 22. Core Areas Big Data Issues Terminology & Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard Common terms Definitions Technical Design Technology Linkage to outside resources, such as authoritative literature Ontology Taxonomy 2. Identifying common obstacles Disagreement Understandabil ity Granularity Costs Integration Usable Costs Integration Usable Complexity Accessible Useful 3. Implementing ongoing development & evolution Widely used Obsolescence Updates Governance Feedback loop Widely used Updates Obsolescence Governance Feedback loop Widely used Obsolescence Updates Governance Feedback loop Widely used Obsolescence Updates Governance Feedback loop 28
  23. 23. Core Areas Big Data Issues Terminology & Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. ISO20022 (Umbrella for payments, securities, trade services, cards, FX) Yes XML ASN.1 Yes Varies by setting Yes Varies by setting 2. FIX (Trade capture, post-trade, STP) Yes XML ASN.1 Yes Varies by setting Yes Varies by setting 3. XBRL (Financial reports, US FDIC Call reports, Corp Actions, Mutual Funds, GRC metrics) Yes XML Varies by setting Yes Varies by setting 4. SDRs/TRs (Swaps, cleared and uncleared) Yes Submitter decision Varies Varies 29
  24. 24. Core Areas Big Data Issues Terminology & Dictionaries Communication Standards Reference Modeling Relationship Modeling 1. Leveraging the standard Standard developed for regulators Formality varies by setting XML (Xlink) Varies by setting Formality varies Key part of standard 2. Identifying common obstacles Strongly disagrees that errors affect users’ ability to use w other data sources Frequent, serious errors Envisioned partial human interaction to consume/input Envision users would need separate technology to consume data Expected high difficulty for users to integrate Differences in financial reporting models Key cause of errors Complexity of GAAP 3. Implementing the ongoing development & evolution Formal governance processes Evolution taken into account Formal governance processes Evolution not taken into account Formal governance processes Evolution factored in Formal governance processes Evolution factored in 19
  25. 25. Stakeholders Standard Setters Filers/Preparers End Users Big Data Issues 1. Leveraging the standard External technology and human intervention to make usable Content representative Costly to input learn and input at first If not a vendor: Difficulty with integration Most consume indirectly Better technology/data: RDFOWL,JSON,CS 2. Identifying common obstacles Low cost to learn Frequent, serious errors Very usable w external software tools Very costly at first Frequent errors, but not serious If not a vendor, difficult to deal with errors Serious or very serious errors 3. Implementing ongoing development & evolution Tech meets needs Process for change is easy & Transparent Feedback loop is good State-of-the-art Mostly meets needs Updates difficult Not transparent Not State-of-the- art If not a vendor, processes for change not transparent, not heard,not state-of- the-art 20
  26. 26. 32
  27. 27. *Views on Big Data *The 3 Vs and if BD even applies… *Entity Identifiers and LEI *Product Identifiers and UPI *Software tools that help… or not… *Recommendations *For the standard or setting *For us 33
  28. 28. * “Overly complex XBRL standard which is implemented inconsistently across the user base. Differences in GAAP/IFRS standards, differences in implementations, XBRL/iXBRL, closed- versus open taxonomies - to name a few.” * “XBRL standards-owners are very few legacy pioneers who have resisted any and all suggestions and ideas to evolve and change, including those coming from W3C members” * “People keep saying 'how the data is structured doesn't matter, what matters is what data is structured ' -- so they write off arguments like 'too complex.' But the 'how' is incredibly important to people thinking about using the raw data.” * “Information is spread out over multiple documents -- none of it is intuitive. Every other markup language 'just makes sense.' You should be able to excerpt the data and understand it.” * “Suggestions: 1. Adopt iXBRL format for XBRL, 2. Re-architect the taxonomy extension concept with RDF/SKOS standard 3. Eliminate XLink and replace it with RDF semantic elements” 34
  29. 29. *Views on Big Data *The 3 Vs and if BD even applies… *Entity Identifiers and LEI *Product Identifiers and UPI *Software tools that help… or not… *Recommendations *For the standard or setting *For us 35
  30. 30. *Filers will do what they are asked, and no more *Compliance does not = success *Regulators’/Designers’ willingness to adapt/evolve/admit mistakes/make changes is important *Data gathered does not = useful or usable information *End user “use cases” throughout the design and implementation may spare a lot of pain afterwards *Actual (not imagined) end users, that is *Their worst case will be a better test than a designer’s wildest imaginary use case *Our pilot survey needs improvements 36
  31. 31. * “Market standards must meet the following challenges to promote and maintain industry-wide adoption. They must: • Fulfill the needs of users, not the perceived needs of ‘professional standardizers’. • Respond quickly to business and market changes. • Stay relevant to the businesses and markets that they support. • Be inclusive and allow the contributions and feedback of stakeholders and users to be included in the standards development and revision processes. • Be international in scope and internationally accepted. • Have continued access to, availability and participation of the necessary technical and subject matter experts as standards development is a voluntary effort. They must attract new participants and stakeholders to the standards development process. Those promoting, developing and using standards must maintain and increase collaboration…” Karla McKenna, representing ISITC in XBRLglobal Vol. 1 Issue 2 – Aug 2010 37
  32. 32. * *“[Relational databases] could be the biggest impediment to progress. It’s not that we don’t need them, it’s just not where the real world Big Data problems are coming from. We know how to do that and it’s all in the past. Today’s data doesn’t fit into relational databases.” *Does it make sense to structure unstructured data (using tags, NLP, taxonomies)? “I do not think so. I think you should avoid doing violence to the data. Companies need to find ways to deal with the data as-is. They can do this by seeking out partners and vendors that specialize in analysing these data types. We spend a lot of time forcing old methods on to new things, but that’s not useful with data. You need to find new ways to manage the variety of today’s data.” Dr. Roy Marsten, in interview with Vincent Granville, on Data Science Central, 14 February 2014. 38
  33. 33. *Where does a particular data/standard issue fit right now? *Where will it fit in a year, 3 years, 5 years, 10 years? 39
  34. 34. *Questions? *Comments? *Input? 40
  35. 35. 41
  36. 36. #SISF Common financial language Academic research presentation Alistair Milne, Loughborough University School of Business and EconomicsMalcolm Chisholm, AskGet.com Inc. Yves Bontemps, SWIFT [Discussant]
  37. 37. THE PROSPECTS FOR COMMON FINANCIAL LANGUAGE IN WHOLESALE FINANCIAL SERVICES Swift Institute Working Paper Alistair Milne (Loughborough University) and Malcolm Chisholm (AskGet Consulting) 25/03/201443 Alistair Milne and Malcolm Chisholm: Common Financial Language
  38. 38. The proposition • A universal language for finance “LEIs (global legal entity identifiers) the ‘nouns’ of a common financial language with an accompanying system of product identifier’s (PIs) the corresponding ‘verbs’ ” (Ali, Haldane and Nahai-Williamson (March, 2012) ) • A single common language providing: – dramatically more efficient business processes – comprehensive risk information for firms; and – full regulatory oversight of the system • Analogies – the “barcode” in the global supply chain – the world wide web 25/03/201444 Alistair Milne and Malcolm Chisholm: Common Financial Language
  39. 39. Our findings • A single common language is not realistic • Movement towards a common financial language will be useful for: – specific ‘communities of interest’; and – clearly defined applications 25/03/201 45 Alistair Milne and Malcolm Chisholm: Common Financial Language
  40. 40. Three arguments why ... 1. Theory: Philosophical perspectives – No single, unchanging, underlying financial reality – Plato, Aristotle, Wittgenstein 2. In practice: Industry efforts to develop common definitions and processes are focused and limited – Examples from standard setting in financial transactions • The FIX Protocol • ISO20022 3. An even bigger challenge: position and reference data 25/03/2014 46 Alistair Milne and Malcolm Chisholm: Common Financial Language
  41. 41. Figure 1: relational database design is a constraint Loan Portfolio Table Loan Portfolio Identifier (Key) Loan Portfolio Name Loan Portfolio Delinquent Payment Table Loan Portfolio Identifier (Key) Number of Delinquent Loans Delinquent Day Range (Key) Loan Portfolio Loan Portfolio Name Number of Payments 30-59 Days Late Number of Payments 60-89 Days Late Number of Payments 90-119 Days Late Number of Payments 120 or More Days Late = Concept = Property = Table = Key Column = Non-Key Column A. Representation in Common Financial Language B. Representation in Relational Database Design C. Example of Data in Loan Portfolio Delinquent Payment Table Loan Portfolio Identifier Number of Delinquent Loans Delinquent Day Range MBS2008-01 230730-59 MBS2008-01 311260-89 MBS2008-01 1123490-119 MBS2008-01 5725120+ Column Headers Data Records
  42. 42. Database CFL Database CFL Semantic Adapter Direct Correspondence between CFL and Database Correspondance between CFL and Database achieved by Semantic Adapter (a.k.a. “Abstraction Layer”) Figure 2: the problem and a possible solution
  43. 43. Our findings again • A single common language is not realistic • Movement towards a common financial language will be useful for: – specific ‘communities of interest’; and – clearly defined applications 25/03/2014 49 Alistair Milne and Malcolm Chisholm: Common Financial Language
  44. 44. • Swift Institute Working Paper http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2325362 • Alistair Milne a.k.l.milne@lboro.ac.uk www.lboro.ac.uk/departments/sbe/research/ce ntres/cpcf • Malcolm Chisholm masterdataconsulting@googlemail.com www.askget.com 25/03/201450 Alistair Milne and Malcolm Chisholm: Common Financial Language
  45. 45. Macroprudential oversight, risk communication and visualization #SISF Peter Sarlin, Goethe University Frankfurt
  46. 46. Presentations #SISF The future of standards Coffee break Panel sessions
  47. 47. Stuart Weinstein, Coventry Law School #SISF The future of standards Andrei Kirilienko, MIT Sloan School of Management
  48. 48. Professor Stuart Weinstein Coventry Law School Faculty of Business Environment and Society 25 March 2014 – Future of Standards
  49. 49. Academic Problem Statement • The famous quote that ‘England and America are two countries separated by a common language’ has often been attributed to George Bernard Shaw. • When it comes to derivatives regulation, Shaw’s wry observation also rings true. It can be said that the two regulatory regimes are also separated by a common language. • While the two regimes deliver broadly the same outcomes in respect of the key regulatory goals, the devil is in the detail in that there may be technical differences in requirements that trip up the unwary.
  50. 50. The regulatory puzzle • No one doubts that coordination of OTC derivatives market is necessary to reduce systemic risk, improve transparency, support financial stability and combat market abuse. • OTC derivatives are a global market yet regulators operate on a nation state level only. • So, how do you coordinate among jurisdictions to close the gaps, reduce the potential for arbitrage opportunities and foster a level playing field for market participants, intermediaries and infrastructures?
  51. 51. Different solutions – different outcomes? • Legal systems and market conditions differ among jurisdictions necessitating different regulatory solutions. • Jurisdictions should be able to defer to each other when justified by the quality of their respective regulations. • Enforcement regimes based on essentially identical outcomes applied in a non-discriminatory way means that banks must pay due respect to their home country regulation regimes. • But, do these different solutions in reality produce different outcomes?
  52. 52. There are distinctions but not fundamental core differences. • The differences, however, are for the most part not significant. • Nor do they impede the critical goal of achieving roughly comparable outcomes. • There are distinctions but not fundamental core differences. • To butcher George Bernard Shaw’s adage: “two regulatory regimes separated by a common language”. • A worldwind tour follows on!
  53. 53. Different Reporting Requirements • In the area of swap data reporting, there are differences in timing – in the US ranging from 30 minutes to 48 hours depending on information reported and reporting counterparty and in the EU no later than T+1. • Exchange-traded derivatives must be reported in the EU. In terms of the reporting counterparty, the US requires one but the EU mandates this is done by both counterparties with information on collateral being reportable in the EU.
  54. 54. Clearing and Swap Processing • Standardised OTC derivatives will be centrally cleared by well-regulated entities to reduce counterparty credit risk to protect client monies. • US: credit and interest rates products go first with others added later but FX swaps and forwards are exempt. • EU: Exact product set to be determined but overall scope captures credit, interest rates, FX, equity and commodity derivatives.
  55. 55. Clearing and Swap Processing • Collateral Segregation: Omnibus segregation approach in the EU. Individual segregation, however, must be offered with clients choosing the approach. • The Legally Separated Operationally Co-mingled model is used is in the US. • Exemptions: EU has a 3 year exemption for pension funds and non-financial counterparties are exempt if non-hedging trading volume falls below certain thresholds.
  56. 56. Clearing and Swap Processing • Inter-affiliate Scope for Exemption: Exists in the US for the exchange of initial margin (IM) while in the EU both IM and variation margin are covered. • Historical Contracts: In the EU, trades outstanding at the time of a notification to clear (and subsequently subject to a clearing obligation) must be cleared but in the US trades executed before the clearing obligation is determined will not have to be cleared.
  57. 57. Mandatory Trade Execution • In the US, for Available to Trade if the trade is standardised and ‘clearable’ it must be traded electronically. • In the EU, clearing eligible and ‘sufficiently liquid’ derivatives must be traded on an exchange or organised trading venue.
  58. 58. Portfolio Conciliation and Compression - Disputes In the US, financial counterparties must report disputes that are unresolved after 5 business days and ≥$20m while in the EU they must report disputes which are >€15m and outstanding for at least 15 business days.
  59. 59. Trade Confirmation • In the EU, both counterparties must confirm all trade terms while in the US this obligations falls on Swap Dealers and Major Swap Participants.
  60. 60. Daily Trading Records • The US wants records of the cash and forward transactions to hedge swaps kept and trade reconstruction indexed to both counterparty and the trade. • The EU requires reporting to a trade repository and transaction details reported to the regulator no later than T+1 but as soon as possible.
  61. 61. External Business Conduct Standards • Transactions with US counterparties must comply with all CFTC requirements including daily mid-mark, compliance and Material Economic Terms Disclosure while in the EU financial counterparties must take reasonable steps to ensure the best possible result when executing orders for their clients.
  62. 62. Law of Unintended Consequences – US “Shadow Banking” • Overlapping regulation for the banking & derivatives markets means risk is being transferred into the more lightly regulated "shadow banking” market - a gap the rules were supposed to rein in. • US OTC derivatives clearing requirements will create problems because clearing house structures are fragile meaning collateral will have to come from the banking system and, crucially, the shadow banking system (institutions such as pension funds and hedge funds) which do not have access to central bank money.
  63. 63. Law of Unintended Consequences – US “Shadow Banking” • While it is unknown how much collateral will be needed, much of it will come from the “shadow banking” systems potentially increasing systemic risk. • Query: Could not standards address the collateral problem more effectively and efficiently than regulatory fiat?
  64. 64. EU – Vertical Silos to Collapse? • European regulators are considering rules that may require clearing houses to be interoperable. • While this will allow customers to access open interest positions in contracts at rival venues. • This could hurt vertical silo operators as customers could have a swap open at one clearing house and have the position offset by a swap cleared at another clearing house. • Query: Could not standards address the lack of interoperability problem more effectively and efficiently than regulatory fiat?
  65. 65. Conclusions • While the two regimes deliver broadly the same outcomes in respect of the key regulatory goals, the devil is in the detail in that there may be technical differences in requirements that trip up the unwary. • There are distinctions but not fundamental core differences. • Greater use of standards to address knotty problems such as shadow banking and the lack of interoperability might be more effectivel and efficient than regulatory fiat.
  66. 66. Thank You. Stuart.Weinstein@coventry.ac.uk
  67. 67. Implementing Financial Regulations: What’s lost in translation? What can we do about it? Andrei Kirilenko MIT Sloan
  68. 68. Implementing Regulations: A CIO Perspective From an e-mal to me: “I have now been at [ ] for over a year and have seen us struggle with trying to bridge the gap between rules that are written by lawyers and then translated into code by our development team. In nearly all cases, the rules, design of the solution and the development and testing are all happening in parallel which opens us up to the risk that a lawyer changes a sentence late in the process that has a meaningful impact on our actual code. As you can imagine, when found before we go live with the software change, this results in delays, rework and extra testing. When found after we have gone live in production, this can result in regulatory action including monetary fines. “
  69. 69. Lost in Translation Modern financial markets are complex adaptive systems of computer algorithms. Yet, the regulatory framework is still fully human- centric. Human regulators are writing rules with the idea that they would be interpreted and implemented by a human market operator. There is, indeed, a human operator, but it is no longer a trader or a regulatory compliance officer of the past. Instead, it is a software architect or a computer programmer who has to translate regulations into lines of computer code. This creates a possibility of a significant amount of intended regulatory content to be “lost in translation.”
  70. 70. Framework: Type I and Type II Errors There are two types of implementation errors. Type I (false positive) implementation error means that the regulatory content that is NOT INTENDED to be implemented, is IMPLEMENTED. Type II (false negative) implementation error means that the regulatory content that’s INTENDED to be implemented, is in fact NOT IMPLEMENTED.
  71. 71. Type I and Type II Errors: A Reminder
  72. 72. Type I and Type II Errors: Costs and Efficiency Each error is costly. Type I error (doing what’s not needed) results in extra burden: costs, delays, rework. Type II error (not doing what’s needed) may result in regulatory action and fines. Optimal implementation is a tradeoff between Type I and Type II errors. The tradeoff results in an overall loss of regulatory efficiency.
  73. 73. Loss of Regulatory Efficiency
  74. 74. What can be done?: Go from Analog to Digital! Each regulation is a circuit: it allows some things, prohibits others and is neutral over a range of values.
  75. 75. Solution: TID Section in Each Regulation To enhance regulatory efficiency, regulations written for automated financial markets need to include a separate section. The Technological Implementation and Data (TID) section should describe the circuit architecture of each rule in a form of standardized logic gates, truth tables or other alternatives. Circuit architecture can be efficiently implemented by software architects and developers. It could also include scenarios and data required to validate implementation.
  76. 76. Boolean Algebra (0’s and 1’s)
  77. 77. Circuit Architecture: Inputs and Outputs
  78. 78. TID Section Should Offer Safe Harbor The TID section would be akin to the cost-benefit analysis (CBA) section currently required for each regulation, but with one big exception – it should be a “safe harbor” section, not a litigation target. Otherwise, it would quickly evolve into a “litigation risk management” tool that would further add to implementation errors. Safe harbor means that specific implementation protocol as provided in the TID section should be deemed sufficient. Deals with the issue of implementation of principles-based regulations: A trade off then between being more prescriptive and improving regulatory efficiency and being less prescriptive and fostering innovation.
  79. 79. Envisioned Harvard-MIT Experiment 1. Create several HLS-MIT CS implementation teams. Have HLS students read an existing (simple) rule and work with MIT CS students to implement it as lines of computer code. 2. Examine the extent of Type I and Type II implementation errors, if any. 3. Create a flow chart of logic gates that describe how to implement the same existing regulation as a circuit. 4. Have the same number of different teams of similar abilities implement the same rule as lines of computer code aided by the flow chart of logic gates. 5. Examine the extent of Type I and Type II implementation errors with logic gates, if any. 6. Show how much can be potentially “lost in translation” and how it can be avoided. Repeat. 7. Work with the teams to develop a guide that best describes a regulation to them for the purposes of implementation. Call it a prototype TID section.
  80. 80. Financial Regulation 1.0 clearing commission swaps dco customer cleared risk margin dcosmembers derivatives sec member proposed collateral requirement organization financial futuresaccount swap data reporting sdr markettime part block counterparty cl counterparties notional public asset section required requirements compliance foreign msps rules sds rule management affiliate believes msp order final cea act transactions information dodd frank commodity relief entities entity exemptletter formfund advisers funds private investment pf cpos exemption hedge assets sef comment trading trade dcm execution core participants contract position limits contracts note supra positions month referenced price spot cashphysical bona fide based security index exchange commissions securities cftc title vii insurance interpretation regulation retail person merchant regulations registration dealer major dealers participant commenters special definition options agricultural electric option consumer coveredidentity notice action whistleblower theft opt institution banking activities transaction minimum registered rate class size subpart resourcesproceduresii facility board designated agreement fcmcustomers capital segregation model fcms TopicfromFinalRules TopicfromProposedRules
  81. 81. Financial Regulation 2.0 Systems-Engineered. Regulate automated markets as complex systems composed of software, hardware, and human personnel; promote best practices in systems design and complexity management. Safeguards-Heavy. Make risk safeguards consistent with the machine- readable communication protocols and operational speeds. Transparency-Rich. Mandate that versions and modifications of the source code that implement each rule are made available to the regulators and potentially the public. Cyber-centric. Change regulatory surveillance and enforcement practices to be more cyber-centric rather than human-centric. Platform-Neutral. Make regulations neutral with respect to computing technologies.
  82. 82. #SISF Panel Lindsay Thomas, former FSA Brendan Reilly, Barclays John Trundle, Euroclear UK and Ireland Emma Kalliomaki, ANNA Kevin Houstoun, FIX Moderated by Natasha De Teran, SWIFT
  83. 83. #SISF Panel Marcus Treacher, HSBC Marc Bayle, ECB Chiara Von Gunten, UK Think tank Z/Yen James Whittle, RMG ISO 20022 Stephen Lindsay, SWIFT Moderated by Natasha De Teran, SWIFT
  84. 84. #SISF #SISF Andrew Muir, SWIFT Virginie O’Shea, AITE Group Gert Raeves, TowerGroup Wrap-up and Closing
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×