System Integration Platforms: Open Finance Laboratory case

© ObjectCentric Solutions, Inc., 2000

 

System Integration Platforms: Open Finance Laboratory case. 1

Business niche. 1

Architecture. 2

Data Model 2

Interfaces. 2

Financial Analytics. 3

Reporting features. 4

Charting. 5

Customization, Expandability. 5

Technicalities. 5

Cost 6

Summary. 6

References. 6

 

Business niche

 

Small and mid-size Financial Institutions

·        Community Banks

·        Credit Unions

·        Lending and Mortgage Bankers

·        Mutual Funds

·        Financial Advisories

·        Boutique Trading

·        Research Groups

·        Education

 

Most institutions within this category would face the same set of problems: to have simple, inexpensive back-office system with support of variety of financial and/or computational models, and user-defined reporting.  This group of clients would rather follow open standards and forums than vendor-dictated solutions. What would be the most valuable set of requirements to satisfy this group of clients?

(i)                  To have kind of boot-able system: start from simple basics and continue to add power utilizing pre-existing data objects;

(ii)                To plug-in financial engineering computational models, data acquisition packages in simple, transparent mode;

(iii)               To support the process of developing new sophisticated financial models;

(iv)              To have customizable reporting system.

Solution: “small” client would need light-weighted system to support flexibility in data modeling, reporting, financial modeling and computational methods plugging-in.

 

Architecture

 

The system core is Open Finance Laboratory Data Model. It is the set of data base objects and operations to manipulate on them. Data Model is utilized by the following set of sub-systems:

1.      RateOpener           – gateway to market rates;

2.      DataMartOpener – tool for navigating, browsing and administrating data model;

3.      InstrumentOpener – financial instruments/positions acquisition agents;

4.      ReportingOpener   - reporting framework.

 

 

 

Data Model

 

Open Finance Laboratory Data Model Manifesto

1.      Compact, expandable data model.

2.      Simple, practical paradigm to construct new instruments from existing ones.

3.      Multidimensional model to represent different factors like position or instruments attributes.

4.      Powerful set of functions to construct factor hierarchies and even graphs.

5.      Simple paradigm for grouping positions into portfolios.

6.      Flexibility in calculation methods plugging in.

7.      Emerging information technology and financial industry standards support.

 

Open Finance Laboratory Data Model Design Principle

“Make modeling simple but not simpler than it actually is”.  Looks like a number of systems can cover some business lines requirements pretty good today, but what if a client needs some enhancements tomorrow? Should the client wait for the new version of the system from the vendor? Or could the client easily customize the system to meet business needs? If the latter way sounds the preferable one, then the question would be how to design the system, which already includes many useful objects/components (NOT definitely EVERYTHING) and also provides the way for the data model customization? Is there a way to find “golden middle”: provide basic (but really useful!) functionality and at the same time keep the door open for client-driven extensions? We would suggest that the data model framework design principle is to be committed to the above-mentioned  “golden middle” philosophy.

Interfaces

 

“Open Finance Laboratory” architecture supports XML-based interfaces for market rates and financial products definition. XML definition for market feeds/financial products becomes standard de-facto and accepts industry-wide support. XML data can be naturally processed on Internet by both, back-office and front-end software.

Here is an (theoretical) example of Bond description to give flavor of XML.

 

<Bond>

            <CUSIP>112233</CUSIP>

            <Maturity>20-6-10</Maturity>

            <Frequency>6M</Frequency>

            <Basis>30-360</Basis>

            <Coupon>6.25</Coupon>

</Bond>

 

Data acquisition agents utilize APIs published by feed providers. Currently under development: integration with Jones Financial Network XML Nebula APIs.

Jones Financial Network (JFN) is a division of Digital Integrator Inc (DI).

DI's objective is to become the worldwide standard for real-time data delivery services to the financial community. DI's backbone is called Nebula, its proprietary server clustering technology. In the financial trading world, Nebula normalizes data from many diverse financial information companies into a homogeneous and unified feed for real-time display on trading screens. A key difference for the DI financial system is its open platform commitment. In contrast to the traditional proprietary systems DI freely distributes programming APIs and end-user tools that allow and encourage the use of its financial data with off-the-shelf equipment through the Internet, Intranet or Extranets.

The Nebula middle-ware can be thought of as a utility that handles complex back-end data integration for companies that are developing e-commerce solutions, business to business web applications, and enterprise applications.

Nebula APIs are available free of charge with low-cost packages. Here is an example of one of the packages.

Features

• Complete, full strength, real-time data
• View off-the-run issues
• News retrieval power
• Real-time charting

Package Contents

• GovPX real-time record-based quotes
• GovPX pages 1 through 218
• Corporate Trades I
• Market News Wire
• FOREX from Harlow Butler
• Dow Jones Indexes



Financial Analytics

 

Architecture permits smooth integration with virtually any financial library.  Current version utilizes SIA-compliant QuantTools-2000 from TechHackers/Unisys. Here is the partial list of supported functions:

-         Business Day Functions;

-         Amortization Functions;

-         Math Functions;

-         Financial Functions;

-         FX Functions;

-         Conversion Functions;

-         Bill Functions;

-         CD Functions;

-         Bond Functions;

-         Option Functions;

-         Mortgage-Backed Securities Functions.

 

 

Reporting features

 

1.      Data model independence and easiness of customization.

The system employs its own meta-data, hence virtually any existing financial system data structures could be mapped onto “Open Finance Laboratory” reporting framework.

2.   Business terminology.

The system components are described in business terms: dimensions, attributes, properties and facts.

3.   Timeless construction of report templates.

Report templates can be built by the end-user (business analyst, business assistant) without any technical assistance. They are simply defined with the use of three components: report layout, report metric and filtering criteria. There could be multiple instances of each report component grouped into folders.

4.      Flexibility of ad-hoc reporting.

Ad-hoc reports are produced by the combination of various instances of report layouts, metrics and criteria (filters); no pre-defined report template is needed.

5.      Business consistent and interactive reports presentation.

Actual report is represented in the form of grid with column and row labels similar to a spreadsheet presentation.

Report may consist of any number of business dimensions (i.e. it’s multidimensional), metrics and filters.

Reports are interactive: there is slice-and-dice, sorting and formatting functionality for any report.

 

6.   Report metrics openness.

Any financial library can be plugged-in by providing a special interface (function properties description) for all functions to be used within the system.

7.   Reporting data openness.

Report can be easily exported to (or import from) a spreadsheet format (i.e. Excel) and published on Internet (in HTML format).

8.   Report presentation openness.

Set of published APIs provides access to the reporting engine from any proprietary reporting presentation or an application.

9.      Reports scheduling.

Reports can be combined into a batch processing and scheduled to run at certain time. For instance, time-consuming reports may be scheduled to run at night.

10.  Reports distribution.

Every report can be distributed to any number of end-users through network.

 

Charting

 

“Open Financial Laboratory” intends to utilize GreenPoint Inc. web charting technology. GreenPoint is a leader in creating enterprise-wide visualization solutions for distributed Web applications. Company provides clients with tools and services that help them to create scaleable and portable applications. WebCharts software allows to publish data in graphical format on any web page within a short period of time as well as to design sophisticated web applications.

Customization, Expandability

 

Data Model

The following mechanisms allow achieving flexibility:

(i)                  Adding new dimension; instrument/position/rates can be tagged by newly created dimension;

(ii)                And, the most important, system can be extended naturally, by creating new objects. Sounds like this is the obvious approach; but did anybody try just jump into proprietary data model and start adding new tables and modify system code? The catch here is the level of granularity of data objects: the lower the level the easier to re-use and customize data objects, and maintain referential integrity.

Market Feeds

Architecture supports XML-enabled interfaces

Financial Analytics

Architecture allows adding virtually any library on client request

Reporting

Tool allows constructing user-defined reports

Technicalities

 

1.                  Implementation database is MS SQL 6.5 / 7.0.  Common subset of  “Transact-SQL” language features, both available in MS SQL and Sybase, has been used.

2.                  RateOpener loads publicly available rates from Federal Reserve Bank web site. Set of classes is written in Java. Rate loading process conceptually consists of three phases: (i) actual loading rate data from URL; (ii) parsing and converting into the appropriate format; (iii) loading into database.

3.                  InstrumentOpener loads (as of today) publicly available descriptive data on the most recent Treasuries auctions from Federal Reserve Bank web site. Descriptive data includes coupon, issue date, maturity date, yield, price, and CUSIP. Developed in Java and conceptually similar to RateOpener.

4.                  DataMartOpener is a generic browsing tool to inspect data objects, based on “primary-foreign” key relationships. Implemented in Java and utilizes Swing classes.

5.                  ReportOpener design principles utilize multi-dimensional data representation paradigm. Written in Java and utilizes Swing classes.

 

Cost

 

The basic system cost is substantially lower than competitive products. Client pays additionally for (1) market feeds; (2) financial analytic library; (3) web charting.

Summary

 

·        Flexible, highly customizable infrastructure

·        Client-driven philosophy

·        Light-weighted, open architecture

·        High quality of engineering solutions

·        Reasonable cost of the entire system, installation , support

References

 

www.objcentric.com  - “Open Finance Laboratory”

www.pctrader.com       - Jones Financial Network

www.thi.com                - QuantTools-2000

www.gpoint.com          - WebCharts