Two Faces of Financial Services Standardization

1. Two FacesofFinancial Services Standardization Richard Mark Soley, Ph.D. Chairman and CEO Object Management Group, Inc. 20 October 2011

2. A Story from My Hometown • Great Baltimore Fire of 1904 • Response from Philadelphia, Washington, New York, Virginia, Atlantic City… hundreds of firefighters • Burned for two days, 60 hectares • Why?

3. Standards Are Important • Sometimes they have life-or-death consequences • Successful standards start, maintain and build ecosystems & businesses • Standards are product differentiators: • Marks of quality • Expertise (certification, validation) • Interoperability, Portability & Reuse

4. Integration is Hard Executive decisions, mergers & acquisitions have a way of surprising us…

5. One Standard? • No…but the cost of adaptation must be low.

6. OMG’s Mission • Develop an architecture, using appropriate technology, for modeling & distributed application integration, guaranteeing: • reusability of components • interoperability & portability • basis in commercially available software • Specifications freely available • Implementations exist • Member-controlled not-for-profit

7. Who Are OMG? Adaptive Atego Boeing CA Technologies Citigroup Cognizant CSC EADS Eclipse Foundation EDS FICO Firestar Software Fujitsu HCL Hewlett Packard Hitachi HSBC IBM Lockheed Martin Mayo Clinic Microsoft MITRE Model Driven Solutions National Archives NEC NIST No Magic NTT DoCoMo Northrop Grumman OASIS OIS Oracle PrismTech SAP SWIFT TCS THALES Unisys Wells Fargo W3C

8. You Can’t Do it Alone

9. OMG & Modeling • Best known for key standards in modeling languages and middleware: • UML (broad software & systems) • SysML (systems engineering) • SoaML (service-oriented architectures) • BPMN (business processes) • CWM (data warehouses) • MOF (modeling languages) • UPDM (enterprise architectures) • CORBA (distributed object-oriented middleware) • DDS (real-time publish & subscribe middleware)

10. OMG’s Focus • Three key “infrastructure” standards foci: • Modeling • Middleware • Real-time & other specialized systems • More than 20 “vertical market” foci: • Healthcare • Financial services • Robotics • Etc. • Focused working groups • Business Architecture • Cloud Computing • All in a common context

11. 21st Century Enterprise: Globalization

12. 21st Century Enterprise: Connectedness

13. 21st Century Enterprise: Digital Markets & Value Chains

14. 21st Century Enterprise: Continuous Innovation

15. 21st Century Enterprise: Change Creation & Adaptation "If you don't like change, you're going to like irrelevance even less.” - General Eric Shinseki, Chief of Staff, US Army.

16. 21st Century Enterprise = Complexity

17. The Enterprise Architecture Mission Create an Environment for: That Embraces: And Manages:

18. This is not an architecture This is not a house An Enterprise Blueprint

19. The Environment Portfolio Planning & Management Business IT Integration Business Agility Platform Enforcement to Compliance

20. Enterprise Architecture in 2010 • Technology Focused • Governance & Control Origins • Business & Technology Focus • Business Advancement • Portfolio Productivity • True Enterprise Level Function

21. Traditional Business and IT Collaboration

22. STANDARDS Service-Oriented World Business and IT Collaboration EA 2010

23. Beware the Alignment Trap "A lack of alignment can doom IT either to irrelevance or to failure”. “…a narrow focus on alignment reflects a fundamental misconception about the nature of IT. Underperforming capabilities are often rooted not just in misalignment but in the complexity of systems, applications and other infrastructure.” “Aligning a poorly performing IT organization to the right business objectives still won’t get the objectives accomplished”. - Avoiding the Alignment Trap in IT, MIT Sloan Review, Fall 2007

24. Enterprise Architects Need Business Smarts “One of my VPs said, I’m never bringing [architect] to another meeting because he opens his mouth and all that ever comes out is SOA, SOA, services-oriented architecture, and I can’t bring him to my business clients. A year later, he is the most articulate business speaker and has really turned the community where they now say, we want [architect] at all of our meetings.” - CIO, Fortune 200 Company

25. You Are Not Alone • There are plenty of organizations that are on this path • There are thousands of people learning to be enterprise architects and spanning the business/technology gap • From the standards perspective, modeling is an important way to understand systems • That’s not a particularly new idea, see bridge-building • Don’t forget where the word “architecture” came from • There are organizations that bring together people • Business process excellence: service architecture meets the business • Object Management Group: business architects & modeling standards

26. Financial Services Standards Proliferation • The Financial Services world already features dozens of standards • In inter-bank payments & trading alone, hundreds of standards, near-standards, in-house standards and one-off solutions: ISO 20022, ISO 15022, MT, FIX, FpML, IFX, etc. • Financial services richly displays the “N+1 Problem” – one standard to rule them all

27. Two Standards in Financial Services • Let’s focus on two specific OMG standards • Consortium for IT Software Quality • Increasing the measured quality of delivered software • OMG’s Financial Services Task Force: Financial Industry Business Ontology • Increasing the interoperability of financial services messaging and reporting without increasing complexity

28. Software Quality: The Problem Regardless of methodology & approach, the biggest problem in IT today is inconsistent and unreliable software quality Cloud computing and SOA make the problem 10 times worse: you must rely on software you don’t own, you don’t see, you don’t control, and you can’t fix CMMI solves the process problem, but doesn’t address the product problem.

29. The Software Quality Dilemma National Research Council Software for Dependable Systems “As higher levels of assurance are demanded…testing cannot deliver the level of confidence required at a reasonable cost.” “The cost of preventing all failures will usually be prohibitively expensive, so a dependable system will not offer uniform levels of confidence across all functions.” “The correctness of the code is rarely the weakest link.” Jackson, D. (2009). Communications of the ACM, 52 (4)

30. Software Engineering’s 4th Wave What: Architecture, Quality characteristics, Reuse When: 2002 Why: Ensure software is constructed to standards that meet the lifetime demands placed on it 4 Product What: CMM/CMMI, ITIL, PMBOK, Agile When: 1990-2002 Why: Provide a more disciplined environment for professional work incorporating best practices 3 Process What: Design methods, CASE tools When: 1980-1990 Why: Give developers better tools and aids for constructing software systems 2 Methods 1 What: 3rd & 4th generation languages, structured programming When: 1965-1980 Why: Give developers greater power for expressing their programs Languages

31. Why CISQ? Industry needs software quality measures: Visibility into business critical applications Control of outsourced work Benchmarks Current limitations: Manual, expensiveinfrequent use Subjectivenot repeatable or comparable Inconsistent definitionsburdens usage

32. What Is CISQ? Partnership CISQ IT organizations, Outsourcers, Government, Experts IT Executives Technical experts Define industry issues Drive standards adoption Application quality standard Other standards, methods Technical certification

33. CISQ Members

34. Initial CISQ Objectives Raise international awareness of the critical challenge of IT software quality 1 Develop standard, automatable measures and anti-patterns for evaluating IT software quality 2 Promote global acceptance of the standard in acquiring IT software and services 3 Develop an infrastructure of authorized assessors and products using the standard 4

35. Integrating Existing Standards Knowledge Discovery Meta-model Structured Metrics Meta-model Technical Work Groups Defined Measures ISO 25000 14143 27000 Function Points Maintainability Best Practices CISQ Exec Forum OMG ISO 15939 Reliability & Performance Weaknesses& Violations Security ISO 17799 CVSS Methods for Metrics Use Pattern Metamodel; KDM

36. Another Example: FIBO • Financial Industry Business Ontology • Industry initiative to define financial industry terms, definitions and synonyms using semantic web principals and widely-adopted OMG modeling standards • A joint effort of the OMG and the Enterprise Data Management Council (EDM-C) • Driven by immediate requirements to capture financial surveillance (reporting) data (e.g., Dodd-Frank laws in the United States and similar post-2008 rules worldwide) • Relentlessly focused on not reinventing but integrating existing standards (avoid the “N+1 Problem”)

37. Financial Industry Business Ontology Securities Financial Industry SME Reviews Graphical Displays ISO 20022 FpML FIBO Representations Industry Standards Input Corporate Actions Built in Term, Definition, Synonym XBRL OMG Business Entities Derivatives Loans Generate RDF/OWL UML Tool (via ODM) Semantic Web Ontology

38. Initial Mission & Goals • Mission Statement: Demonstrate to the regulatory community and the financial services industry how: • semantic technology and the Financial Industry Business Ontology (FIBO) model can be effectively utilized to fulfill: • regulatory governance • data standardization • risk management • data analytics requirements • specified by the Dodd-Frank legislation • using currently available data sources and messaging protocols • Intent: To encourage open discussion and sharing of ideas among regulatory and financial industry stakeholders about the value and applicability of semantic solutions to effectively realize transparency, risk mitigation and systemic oversight objectives • Members include 89 major financial institutions worldwide (BOA, Barclays, Citigroup, Deutsche, Fannie Mae, Federal Reserve Bank NY, HSBC, Goldman Sachs, JP Morgan Chase, Morgan Stanley, RBC, RBS, UBS, Wells Fargo, etc.

39. Initial Drivers & Strategy • 1) Define Uniform and Expressive Financial Data Standards • Ability to enable standardized terminology and uniform meaning of financial data for interoperability across messaging protocols and data sources for data rollups and aggregations • 2) Classify Financial Instruments into Asset Classes* • Ability to classify financial instruments into asset classes and taxonomies based upon the characteristics and attributes of the instrument itself, rather than relying on descriptive codes • 3) Electronically Express Contractual Provisions** • Ability to encode concepts in machine readable form that describe key provisions specified in contracts in order to identify levels of risk and exposures • 4) Link Disparate Information for Risk Analysis * • Ability to link disparate information based upon explicit or implied relationships for risk analysis and reporting, e.g. legal entity ownership hierarchies for counter-party risk assessment • 5) Meet Regulatory Requirements, Control IT Costs, Incrementally Deploy • Ability to define data standards, store and access data, flexibly refactor data schemas and change assumptions without risk of incurring high IT costs and delays, evolve incrementally *Swap Data Recordkeeping and Reporting Requirements, CFTC, Dec 8, 2010 *Report on OTC Derivatives Data Reporting and Aggregation Requirements, the International Organization of Securities Commissioners (IOSCO), August 2011 **Joint Study on the Feasibility of Mandating Algorithmic Descriptions for Derivatives, SEC/CFTC, April 2011

40. Meeting Swap Regulatory Requirements • 1) Monitor gross and net counterparty exposures for: • Notional volumes per contract • Current values per swap based on valuation criteria dependent upon market conditions and/or lifecycle events • daily margin • daily mark-to-market • Exposures before collateral • Exposures net of collateral • 2) Monitor across full counterparty breakdowns • Identify counterparty risk concentrations for individual risk categories and overall market • Identify all swap positions within the same ownership group • 3) Identify products in a categorical way • Aggregate and report swap transactions at various taxonomy levels of asset classes • Establish position limits that spans across futures, options, and swap markets *Swap Data Recordkeeping and Reporting Requirements, CFTC, Dec 8, 2010

41. Initial Drafts & Proof of Concept 1) Provide Standard Financial Data Terminology using Semantics Provide standardized and unambiguous terminology that can electronically describe the content of an OTC Swap (and related financial terms) using the FIBO conceptual model and ontology. 2) Provide Semantic Mapping between FpML and FIBO Provide mapping between messaging protocols e.g. FpML and common domain models e.g. FIBO to enable interoperability and to avoid imposing changes and alterations to existing messaging protocols 3) Semantically Classify Swaps into Asset Classes Classify swap instruments into asset classes based upon rules that evaluate the attributes and structure of the actual swap data, rather than relying on descriptive codes. • 4) Demonstrate Advanced Semantic Query Capabilities • Provide query capabilities that report legal entity hierarchies, levels of asset class taxonomies, exposures of risk across ownership groups and asset classes (phase 2), as well as extract data to be used for risk analytics 5) Semantically Define Contractual Provisions to Infer Counterparty Risk Categories Demonstrate how provisions of master agreements (e.g. calculations of net exposures, timing of transfers of collateral, forms of eligible collateral etc.), can be electronically realized to infer levels of counterparty financial risk (phase2).

42. That’s Just the Beginning • In financial services alone, OMG is also defining • Property & Casualty insurance models • XBRL abstraction mechanisms for corporate reporting (with XBRL International) • Business event-based costing models • Other standards groups at OMG focus on • Healthcare: defining healthcare systems interoperability standards (with HL7) • Automotive systems assurance • Smart energy grids • Military & commercial communications (software radio) • Space systems interoperability • Over a dozen other market areas • End-user focused groups help make transitions • Cloud computing (fastest growing group at OMG) • Business process excellence (business architecture & planning)

43. Contacts OMG: http://www.omg.org/ Financial Services Standards: http://finance.omg.org/ Software Quality Standards: http://it-cisq.org/ Cloud Computing: http://www.cloudstandardscustomercouncil.org/ Business Excellence: http://www.business-ecology.org/ Richard Soley: soley@omg.org