About a-team Marketing Services

A-Team Insight Blogs

The Quest for Meaning in Financial Systems

Subscribe to our newsletter

By Mike Bennett, director of Hypercube

We are all of us wiser than we were earlier in the year. The credit crisis, at its heart, is a crisis of knowledge: if we knew the right things at the right time, it seems that fund managers might have made different decisions, regulators could regulated and so on. Everyone from Alan Greenspan downwards has said that if we had a better data we might have done things differently.

A number of forward looking firms have already been looking at ways to improve the management of data in their firms, working towards the goal of having a single representation of the truth.

But can you have truth without meaning?

The data we use starts its life with clear enough meanings: terms defined in legally binding contracts or term sheets, prices quoted on trading venues and so on. Somewhere along the line, the meaning seems to get eroded.

The industry has recognised this problem for some time, and a lot of time and effort has gone into standardisation efforts for market data messages, securities data models and so on. Somehow these didn’t deliver what the industry really wanted. Handing the problem to a technical team to create a message or a data model does not solve the problem, it merely gives you a message or a data model, making it more obvious that the problem of common terms and definitions is not a technical problem to begin with. What is really needed is a standardisation of the terms themselves.

For example, an ISO committee was set up to define a common securities data model. Having sat on that committee I can say that the business subject experts were of the highest calibre, and a large number of terms were defined, collected and put into the data model. However, as soon as the model was shown to people who had not sat around the table, the questions started rolling in. Some 70% of the questions were along the lines of: “what does this mean?”, “is this the same as one of those?” and “what does this complex model structure actually show?” The model was a mix of meaningful business knowledge and technical model design. For example there is a term ‘other instrument identifier’. Does this mean another identifier for the same instrument, or the identifier of some other (underlying) instrument? Or both?

This is the problem with trying to set up definitions for data elements or message fields. Sometimes a different word means the same thing; sometimes the same word means something completely different. Does redemption for a bond mean the same thing as redemption in a fund? If not, can the same word be used and have two meanings? A good database design will combine common terms wherever possible, such as redemption and coupon payment streams. Good design pushes out knowledge.

Realistically you can’t deal with meanings by focusing on words. You can get a group of business experts in a room to argue all day about the meaning of a word; what you really want to do is find out all the meanings they know about. What the industry really needs to capture is the semantics of the terms themselves not the words, message tags or database field names.

Can this be done or is it an impossible, philosophical sounding ideal? The technosphere is awash with new terms like semantic technology, OWL and web 3.0, which appear to offer an answer to the problem of capturing those elusive meanings?

Using these semantics tools should be approached with caution. Anybody can pick up a semantics tool and create a model that mixes meanings with design features. You can import a data model into a semantics format and it will still be the same data model with the same design content and the same ambiguities, but in a different language.

What needs to go in a semantics model is real world things, and the facts about each of those things. So for example a bond is a debt instrument, which is a contract. An interest payment is an event. These are the simple facts we need to capture before we design anything.

There are two important features to a semantics model: everything is defined as a kind of ‘thing’, and each thing has facts that distinguish it from another thing.

Having a given set of facts makes something a member of the set of all things that have that fact. So everything with a backbone is a vertebrate. If a given thing has all the facts relating to a collateralised debt obligation, then it is a collateralised debt obligation. If it walks like a duck, swims like a duck and quacks like a duck, it is a duck. Because this uses set theory, it does not require the business domain expert to understand any computing concept.

For example, if I ask you what a Wertpapier is, you will tell me two things about it: what sort of thing it is (a debt instrument) and what facts about it distinguish it from other debt instruments. It is these two mechanisms: defining where something sits in the universe of things, and what facts distinguish it, that allows a meaningful definition of the terms.

Creating a semantic model requires skill, imagination and insight. The real skill lies in managing to not design something. Creating a semantic model requires getting business experts together, but also facilitating what they do so that their knowledge is captured for all time in a format that deals with the semantic issues.

An example of this approach is the EDM Council Semantics Repository (www.hypercube.co.uk/edmcouncil). This defines everything as a ‘thing’, along with definitions and relations in a technology neutral semantics format. This will be peer reviewed by subject matter experts until it represents an industry consensus on the terms and definitions behind financial data. This will be an industry resource that anyone can refer to for technical development and integration.

Subscribe to our newsletter

Related content

WEBINAR

Recorded Webinar: How to optimise SaaS data management solutions

Software-as-a-Service (SaaS) data management solutions go hand-in-hand with cloud technology, delivering not only SaaS benefits of agility, a reduced on-premise footprint and access to third-party expertise, but also the fast data delivery, productivity and efficiency gains provided by the cloud. This webinar will focus on the essentials of SaaS data management, including practical guidance on...

BLOG

SIX Invests in BITA to Enhance Global Benchmark Platform and Expand Indexing Technology Services

SIX, the Swiss financial data and market infrastructure provider, has made a strategic investment in BITA, the indexing technology and services company. The move aims to bolster a range of ongoing joint projects and fast-track the global expansion of SIX’s benchmark platform. Existing BITA shareholders, including ETFS Capital, Volta Ventures, and Pamica NV, have also...

EVENT

TradingTech Summit London

Now in its 13th year the TradingTech Summit London brings together the European trading technology capital markets industry and examines the latest changes and innovations in trading technology and explores how technology is being deployed to create an edge in sell side and buy side capital markets financial institutions.

GUIDE

Best Practice Client Onboarding

Client onboarding is central to the success of banks, yet it continues to present challenges and the benefits of getting it right are difficult to achieve. The challenges arise from siloed systems, manual processes and poor entity data quality. The potential benefits of successful implementation include excellent client experience, improved client acquisition and loyalty, new business opportunities, reductions in costs, competitive advantage, and confidence in compliance.