Hooking Fixed Income up to The Grid

1
Hooking Fixed Income up to The Grid

• Decentralizing support for investment decisions

2
Agenda

• Description of our Business
• Role of our Group
• Technological Problems We Face
• Java-based Solutions We Propose
• Implications for Wider IT Audience

3
1
Our Business
4
Our Business

• Institutional Fixed Income
• US-only until recently, now Global
• Actively managed against Benchmarks
• Use wide-variety investment grade fixed income
  instruments
• Basically anything in the Lehman Aggregate

5
2
Our Group
6
Our Group

• Perform Investment Research Using Quantitative
  Methods
• Recommend/Develop Analytic Tools
• Provide Support for Use of Research in Investment
  Process

7
Supporting Our Fixed Income Fund Managers

• Complex instruments
• Value of instruments depends explicitly on large
  number of exogenous variables (yield curve moves,
  consumer prepay behavior, credit perceptions)
• Noisy data (cant necessarily trust prices or
  credit)
• Decisions must be made in near-real time
• Extremely high cost of delays
• Assume that portfolio managers and traders apply
  a 25/week discount factor to our future
  deliverables

8
Scope Requirements

• Multi-currency
• Multi-sunset
• Multi-site (Survivability)
• 24x7 Operation
• Reliable
• Available
• Serviceable

9
The Process

• Gather positions (Benchmark and internal)
• Gather observed pricing
• Calibrate market model factors to current pricing
  
• Generate scenarios for interesting variables
  (e.g. yield curves, prepays), translate to model
  factors
• Simulate security behavior under generated
  scenarios
• Aggregate results of simulations
• Analyze Risks/Recommend trades
• Lather, rinse, repeat

10
Internal Services - Model Calibration

• Fit Term Structure
• Treasuries
• Agencies
• Swaps
• Fit Prepays

11
Internal Services - Scenario Generation

• Standard Sensitivity Scenarios (Duration,
  Convexity)
• Specific Macro Economic Scenarios (e.g. Treasury,
  Swap, Agency rates)
• Specific Micro Economic Scenarios (e.g. Auto
  sector, Ford, GM, spreads)

12
Internal Services - Simulation

• Cover ALL instruments
• Cover ALL Scenarios
• Lots of Paths
• Highly Parallelizable at Small Granularity

13
Internal Services -Risk Analysis/Trade
Recommendation

• Lots of Techniques
• What-if Analysis

14
3
Our Problems
15
Technological Problems We Face

• Pick up the tempo
• From nightly to real time
• And everything in between
• Pick up the scale
• More instruments
• More portfolios
• Pick up the accuracy
• Basically more, more, more of everything

16
Observations on the New Technology Environment

• Newly cost insensitive items
• Operating Systems
• Databases
• Virtually unlimited storage with arbitrary
  granularity and linear costs

• Remaining cost sensitive items
• Bandwidth costs based on distance with jump
  discontinuities
• Computational nodes with large granularity and
  nearly exponential costs

17
The Bandwidth Scaling Problem

• Must optimize solutions to cost/distance
  constraints
• Large computational grains can go long distances
• Small grains go shorter distances
• Tiny grains stay in process

18
The Computational Scaling Problem

• Single process space just not fast enough
• Single process space just not big enough
• Costs of adding capacity grow exponentially
  rather than linearly

19
4
Our Solutions
20
Java-based Solutions

• Why Java?
• We bought into OOP long ago, not really the
  deciding factor any more
• Standards well adapted to problem (J2EE,
  Servlets, Jini, JMS, et al.)

• Initial costs low (i.e. none) for reference
  implementations of standards
• Lets us focus on development of our value added
  software, less on infrastructure
• Performance is a concern
• Use of standards and low costs overcome it

21
Implications for Vendors

• Free software will play an important role (we
  agree with IBM on disruptive capabilities of open
  source)
• Generalized shrink wrapped solutions will be an
  increasingly difficult business model to use in
  selling software (How do you compete with free?)
• Customers will be looking for service products
  and highly specialized components rather than
  end-to-end applications.
• Services must connect to internal systems via
  standards
• Components must run inside of standard containers
• External services will be kept honest by
  possibility of rolling internal services quickly,
  cheaply

22
The Grid
That to which services and components attach
themselves is The Grid
23
What are Grid Services? (And Why Do I Care?)

• Using Globus as an example
• File Transfer and Replication
• Security
• Resource Management
• Resource Discovery and Monitoring
• Packaging

24
What are Grid Services? (And Why Do I Care?)

• As conceived by IBM, Sun, Globus, et al.
• Primarily geared towards scientific use
• Designed to support a wide variety of problem
  domains
• Language Neutral
• Database Neutral
• Hardware Neutral

25
What are Grid Services? (And Why Do I Care?)

• As conceived by us
• For businesses, especially Finance/The Street
• Domain-specific
• Java-based (okay, some JNI to C)
• SQL driven RDBMS for data storage
• Intel/Sparc hardware

26
How to Bridge the Gap

• Identify specific services we need
• Identify overlaps with the toolkits from Vendors
• Remove the broad generalities from our
  implementation (i.e. the stuff that someone else
  can do more cheaply like file transfer and
  security)
• Use the common components in our service-based
  environment
• Dont reinvent any wheels

27
Grid Services We Need

• External
• Pricing
• Indicative Data
• Positions

• Internal
• Well-defined Computational Services!
• Reporting/Aggregation
• Data visualization

28
Revisiting the Requirements as Computational
Services

• Calibration of Term Structure Models
• Calibration of Prepay Models
• Scenario generation
• Cashflow Simulation
• 15 year old idea
• Lots easier said than done
• Major consumer of resources
• Portfolio Construction
• Big optimization problem
• Wide variety of heuristics will probably be end
  point

29
The Grid
We need a massively parallel, distributed,
standards-based architecture in which to
implement our vision of The Grid
30
Which Java Technologies Enter the Mix?
UI

• Servlets

• JSP

Front-end Infrastructure

• Jakarta/Tomcat

• JMX

Back-end Infrastructure

• Jini/JavaSpaces

• JMS

• J2EE

31
Jini /Jxta / Web Services

• Some functionality overlap between the 3
• WS and JXTA are language neutral
• Jini assumes Java (or at least Java wrappers
  everywhere)
• WS is wire-heavy with XML and SOAP
• WS and JXTA much more point-to-point and not as
  suited for computationally driven, highly
  parallel systems like front-office fixed income.

32
JavaSpaces

• It aint just chat and whiteboards anymore!
• Object-based shared memory system
• Originated in tuple spaces (e.g. LINDA)
• Allows us to move from synchronous parallelism
  model to asynchronous event-drive model
• JavaSpaces hides PTP aspects but they are there

33
JavaSpaces/JMS Comparison

• Logically Connectionless Communication (Different
  in implementation details)
• Event notification (Very similar)
• Matching (Objects vs. Strings)
• Take semantics (Only in JavaSpaces)
• Perfectly suited for problems which can pool
  connectionless resources

34
Using the Best Concepts of JMS and Javaspaces

• JMS Topics are an intuitive way of segmenting JS
  Entries
• Topics provide natural way to organize multiple
  JavaSpaces
• JS Take semantics are important for the
  simulation and fitting problems
• Moving prices and positions is more like JMS

35
Problems in Both

• Security/Authentication
• Currently poor (Nothing worse in a Wall St.
  environment than being poor!)
• Getting better
• JMX not in reference (aka free) implementations
• Reference implementations need management and
  deployment tools

36
Deutschs Eight Fallacies

• Essentially, everyone, when they first build a
  distributed application, makes the following
  eight assumptions. All prove to be false in the
  long run and all cause big trouble and painful
  learning experiences.

1. The network is reliable 2. Latency is zero 3.
Bandwidth is infinite 4. The network is secure 5.
Topology doesn't change 6. There is one
administrator 7. Transport cost is zero 8. The
network is homogeneous
37
Our Evolving Architecture

• Web-only UI (Servlet-based) that avoids heavy
  bandwidth use and scripting
• JNDI/LDAP-based Authentication, Directory
  Services
• Using JBoss for JMX capabilities as Service
  container
• Using Jakarta Tomcat embedded in JBoss for UI
  Access to Worklet Container

38
Patterns of Design

• Economy
• Required for external resources
• Will require interaction with vendors

• Master/Worker
• Good for internal resources
• Very similar to JMS model

39
Worklets

• Exist in a WorkletContainer
• Patterned after Servlet Containers
• Extremely simple life cycle
• Event driven
• Light on system resources (e.g. No database
  connections)

40
Worklet API

• Initialization
• Concurrency
• Caching
• Subscriptions
• Request/Response Cycle
• Error/Exception Handling

41
Worklet Container Functionality

• Subscription Management
• Context Management
• Space/Topic/Queue Connection Management
• Thread Management
• Exception Handling
• Remote Administration/JMX

42
Master Utilities

• Task generation
• Workflow management
• Task synchronization
• Browser handling for UI Masters

43

5
Implications
44
Implications for a Wider Audience

• Services to be built
• Build/Buy Decisions
• Systems to use

45
Services That We Will Build Internally

• Calibration
• Simulation
• Aggregation
• Positions
• Essentially all the things that are specific to
  our business

46
Services That We Need Someone Else to Build

• Topic Locator (finding a JavaSpace to handle a
  Topic)
• Monitors
• Synchronous (GUI)
• Asynchronous (e.g. email)
• Loggers
• Debugging
• Activity tracking
• Auditing
• Indicative/Reference Data Services
• Primary Pricing
• Secondary Analytics

47
The Build/Buy Decision

• Secondary Pricing
• Primary Analytics
• Code movement
• Jinis advantage in this space
• Security
• Value-added services

48
Other Systems That Will Make a Difference

• Blade Servers
• High density, low-cost computational nodes
• Linux
• Highly reliable
• Low-cost
• Well supported tool set
• Apache
• Ditto as a web server