RISK! What Risk?

Like a mirage, the more you look at financial risk the less sure you are about what you are really seeing. Risk is intuitively obvious. Or is it? You would think that with the long history of trading, risk would be really soundly understood. At one level it is; you have less money than you started with. But as you dig into the definitions and drill down you find at the end of the search - nothing! When I say 'nothing' what I really mean is you find a couple of competing definitions, not an absolute statement of pragmatic use about what risk is. Here is the best summary of our current understanding of the nature of risk I could find:

"A search of the financial literature yields many discussions of risk but few definitions. To understand risk, we must understand two streams flowing through the 20th century. One is subjective probability. The other is operationalism. Where they meet, we can understand risk."

Defining Risk, Glyn A Holton. Financial Analysts Journal. Nov-Dec 2004.

We can understand risk but we cannot define it. This looks a little like the situation before Newtonian mechanics came along. Scientists thought they knew on a case-by-case basis how the universe worked but until Newton famously got hit on the head by an apple while hiding in the countryside from the bubonic plague, nothing really tied events together. Later Einstein did the same for another bunch of 'facts' that proved a nuisance to understand.

Here is a bunch of risks that we can define, plus some. So if there is no fundamental way of quantifying risk are we left to assess it purely on a case-by-case basis?

We have found a way of expressing risk in a way the robot can use. Sufficiently general so as to cover a wide range of situations, but in no way a universal principle. Borrowing from many years experience in physical and IT security we don't think of trading as a financial assessment. In stead trading we assess as two asset classes experiencing particular threats. Each threat has one or more balancing countermeasures which can be activated under the right conditions.

Assessing how likely a perceived threat may occur in prevailing conditions indicates if we should activate the countermeasure. Risk, as an assessment of potential loss, is estimated by assessing how many unaddressed threats remain outstanding in the environment. The robot addresses two primary risks and juggles a balance between them. In ridiculously simple terms these boil down to:

First is the risk of not making a profit while out of the market. There is only one effective countermeasure, deciding to enter the market - but many ways of arriving at this conclusion. If after a risk assessment a countermeasure component fires, then it is most probably safe to enter the market.

Second, while in the market, should I now exit. Again, there is only one action to consider but if after a risk assessment a countermeasure fires it is wise to exit. However, if no countermeasure is triggered it is most probably safe to stay in the market.

The robot does not think about winning or losing. Many investors find this perspective hard to work with. It continually assesses its trading activity to figure out if its behaviour is in line with a winning strategy controlled by risk assessments. Individual transactions are almost irrelevant in its assessments. So long as it follows its risk assessment guidelines, overall it always wins. It plays with loaded dice.

We Robots

At an alumni networking meeting the other evening someone asked me to describe our robots. I was stunned to find myself describing the robot almost as a person. This should not come as a surprise. But it did. Our working descriptions when we are discussing behaviour and performance always return to talking about it as a human trader.

Today's ramble is about trying to better describe this mythical trader. It runs something like this:

A robot is an automaton that behaves like an ethical human trader who has the experience and skills needed to meet his/her performance targets in the trading environment in which he/she is knowledgeable and operates. In operation the person it serves and the goal it works towards on his/her behalf is its principle focus.

Its behaviour is not completely self-serving or indiscriminate. It has a degree of awareness about what is right and wrong in the context of the person it serves and the environment in which it operates and prospers.

While it is hungry for growth it is not boundlessly greedy. During trading it seeks consistency over wild opportunism and works within a risk/reward profile agreed with its owner. In making decisions it is autonomous but not autocratic.

Being able to interact with a wide range of distributed systems, owned by many differing organisations, the robot has an inbuilt understanding of data ownership, privacy and the appropriate use of such data with remote systems. In particular fulfilling its obligations towards its owner take precedent over other roles.

It is able to balance its operational obligations towards its manufacture, operator and owner appropriately in such areas as Data Protection, Security (accountability, confidentiality, integrity and availability) and Performance. In achieving this balance it has an awareness of its responsibilities to each entity it interacts with and can respond appropriately.

Extreme Agility

Growth kills. Its one of the maxims of business. Growing too quickly is as bad as growing too slowly. Philosophers and pragmatists agree, its one of the few topics where they find common cause; growth is not only vital but has to be just right for the current prevailing conditions.

On the other hand, everyone seeks instant, unrestricted and boundless success. Now!

As Lao Tzu said in 400 BC, "No tree grows to heaven." Many other philosophers have also noted that building deep and extensive roots produces slow but accelerating, sustainable growth. Conversely, rapid, unbounded growth creates spectacular, colourful short lived blossoms that equally as quickly return to mulch. Business is full of examples of both types.

What has this to do with robotic trading? It is about thinking in metaphor. Does that make it clearer? Probably not... Tag along for a few more paragraphs please.

Our robots are about creating financial growth for individuals and organisations. But we the creators have a day to day problem when creating the software. First, its never been done before so we don't have a known, reliable plan to build to. Second, as we move forward we have to be agile enough to adapt to feedback and experience, initially from ourselves but also increasingly from our users.

Without a plan we cannot progress. However, a detailed plan of what a financial trading robot should look like is not available - hence we work primarily with metaphor. Our primary metaphor for the software is a robot.

Slowly we give it characteristics. We then test these characteristics against what we have projected. Usually we now go back and modify them, repeating this process until the robot passes our tests of acceptable behaviour.

There are two concurrent movements in modern software development, travelling under the names of Agile Software Development and Extreme Programming. What makes these approaches work is not so much the technical details - important as they are - but the glue that makes all the intricacies work is metaphor. Having a metaphor every team member understands and can relate to while they cut the code is the single most important aspect of these approaches.

The beauty of metaphor is it is descriptive without being prescriptive. It helps you to decide what to do without telling you how to do it. It fosters creativity while focusing on results.

In order to achieve extreme agility and pragmatic results quickly - with least effort - we tell stories, paint word pictures of our metaphor and build the metaphor as the glue in our team. We sketch diagrams that fit the story we are telling that explains the metaphore in context and name the code we write to fit the parts in the story. The code we write is the root system feeding everything else we project will follow. It is a broad and deep root system.

It is nearly two years since we created our first metaphor and the software components we now have at our disposal were not dreamt or planned at that stage. They evolved. Many never made it, proving to be dead ends. The aggregate of those that survived the Darwinian testing process give us the shape of today's robot, which is at the same time highly defined but agile enough to go on evolving.

Re-Writing History

Pete and I agree on most things. We are a good balance. My boundless enthusiasm and his cautious nature balance like a yacht running before a brisk wind with a steadying sea anchor deployed. So it comes as a surprise we cannot agree on something as simple as a name for the robot.

Part of the problem is the name in question has become embedded into the code, making it harder to eliminate all reference to it. It would also be a damned sight easier if the name wasn't so descriptive and apt.

Over the past few months as things have started to come together I have found myself saying something like, "I wish I could claim brilliance and foresight about {this latest wonder} but if I did I would just be re-writing history." Which brings me back to the name in question, Trinity.

One evening after a long day of forcing together three independent expert system structures into one operational unit, I was watching a DVD. The Matrix. The code I was working on had a working title but now the module needed naming. In the middle of the DVD the character called Trinity appeared. And that was it. Since then the main robotic module has had the name Trinity.

If I was inclined to re-write history this story would run slightly differently, a little like this in fact:

Our robot models a basic human reasoning structure that follows a BE-DO-HAVE format. These three components may be thought of as providing a planning process, a process that collects the material and data needed to complete the tasks planned and finally the execution of the tasks with feed back of the results to the planning stage so corrective action can be built into the next round. We chose the name Trinity to describe this neat three stage representation encoded into our expert systems.

Pete still doesn't like the name, with its obvious religious connections. I'm somewhat stuck with it and have got used to it. Fortunately released robots are given different names, so this 'under the hood' name doesn't have too much public exposure. Perhaps I should just claim brilliant forsight and just get on with life...

The Laws of Robotics

When I first read Asimov's 'I Robot' it fired up in me an already huge ambition to become a technologist. Tackling technology and social issues through science fiction was not new but it was certainly new to me. Every automation project I have worked on has been influenced in some way by his Three Laws of Robotics but non more so than creating a trading robot.

Read about the Laws in more detail here. They are exquisitely stated, succinct, finely balanced generalizations, reading more like a set of ideals in a declaration of independence than the opaque code we are used to interpreting from our lawmakers:

1. A robot may not harm a human being, or, through inaction, allow a human being to come to harm.

2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.

3. A robot must protect its own existence, as long as such protection does not conflict with the First or Second Law.

As a designer they provide helpful guides through the minefields of privacy, risk, autonomous decision making and of course responsibility.