Basics of Risk Management for Java Developers

In order to deliver value under the name Risk Management we should be able to analyze measure and report the factors that affect business rewards (or profit) and the extent of losses expected from those factors.

I' m no expert in this area but I have to understand it in order to deliver value to the customers of our Software Products. So here I go tying to make sense.

Let me give you a simple example of risk in profits. You own a bank. (Yes, the current trend of paying geeks more for doing less just continues) The banks management projected nice numbers in its profits because they have just given out 30% of the banks capital in loans at 12% interest to be recovered in 5 years. The earnings on paper look very impressive. What the business managers or even the CEO might just not tell you are
1. What are the factors that can cause those paper profits to completely disappear?
2. How will those factors affect the expected profit and capital?

In the current example the factors could be a downturn in oil industry and most of the loan customers have their business in that segment, or a change in foreign currency rates - the local currency suddenly fears very bad against the Dollar or even some unforeseen event like a terrorist attack that almost wipes out the profits of your customers. (Remember the airlines industry after Sept 11/01).

So that is the first important step in risk management is identifying the risk factors that affect your expected rewards.

The next step arriving at a set of values for various combinations of those risk factors against time-steps. This leads to a related set of factors with numbers for their effects that are linked to the occurrence of some other factors. For example a hike in Oil Prices (one factor) causes the occurrence of another factor a change in Fx Rates against USD.
This related set of risk factors with values over a time line is what I call a scenario. How do you arrive at those values - this where you need accurate historical data and some analytic code.
The analytic code analyses events of the past and makes reasonable predictions of events in the future - each event is the effect of change in one (or more) of the risk factors identified earlier.
Even without any analytic code there are clever business minds who can look at historical data for a time period of the past and give a good business scenario projection for a certain time periods in the future.

So we have risk factors, scenarios and finally one more. Instruments, Trades and portfolios.
The difference and relation between instruments, trades and a portfolio is simple to capture for developers.
Consider an instrument to be a class definition. Trades are instances of Instruments. So instruments are the type for a Trade. A collection of trades is a portfolio whatever is the grouping condition for putting those trades together. A Type object pattern in design pattern language is very useful to capture this relationship.

Now let us dig deeper - if you look at how your company assess and reports risk it is mostly on the basis of the numbers in the portfolio and every time a trade changes your risk positions needs to be adjusted. Now, this is most often a time intensive and/or a computationally intensive operation. Measure of Risk is always dependent on Portfolio. We do not touch that.
But the extent of dependency can be reduces by shifting the intensive analytics to be performed against a bag of instruments - the type definition of a portfolio.

This is my logical conclusion after one hour of risk study. I need to pursue it further because as I stated earlier I see value for our customers.

If a Trade is an instance of an instrument then a portfolio is an instance of an instrument group. Now I assume that there is some commonality in risk profiles across two portfolios with the same instrument group. That commonality needs to detailed and pinpointed to some risk multipliers. If you now have this risk profile for a collection of instruments then you can apply it to any number of portfolios in a much faster way than before.

What remains is to abstract Instruments and SetOfInstruments well. Risk factors and profiling should then be applied to SetOfInstruments and the abstraction tested.

I need to get back to work now.

Bye

Static and Dynamic Data Typing in Java

The concept of types is crucial as you progress as a developer. I have actually written java code about 7 years back without fully grasping this concept.

It involves understanding that a class is a type by itself (the implementation type) and can also comply with other types. You then begin to not just appreciate but ensure a clear separation between specification and implementation between interface and class. Even in simple method signatures you begin to be interested and careful about method specification, pre-conditions, effects and dependencies.

I want to focus on something else today that @requires an understanding of types in OO.
The concept and use of static and dynamic data types in java.

Application programs have to remember data. The simple way is to store them in variables.
int i =2; or Customer cust = new Customer("262621");

Every piece of data (including objects) has a type. And the type defines what you can do with that element. So type defines behavior. Types have hierarchies (remember need not be a single hierarchy) but a forest of hierarchies. From this we understand the concept of a generic (higher in the hierarchy) and specific (lower in the hierarchy) types.

A static type is a simple java class that defines fields and methods. I am really interested on how java types encapsulate data. In static data typing each field is statically declared with a type and a name. The variable (the container for data) has a specific type attached to it. Then you expose this field on the public interface of the class by suitable accessory.

Dynamic typing does not define static members. In dynamic typing the container for data has a generic type that can accommodate any kind of data. The problem this creates is that whenever you store (try to remember) data in such a container you loose information as to what the actual type was. The type of data has to be remembered along with the data element as the type of the container is not the type of the data element (as in static typing). More aptly the container type has no relation to the type hierarchy of the date elements that are stored in it. At compile time you do not know what these names or types are. It immediately implies that in a dynamic data type you do not have type safety. Now let me explain what is type safety and more what is the benefit of having type safety.

Consider a static type as follows

class Customer
{
public String getCustomerId()

public Date getBirthDate()

public String getLocationId()

.. fields and method body left out
}

Now, the application dictates that a Customer is allowed a 5% discount but Agents do not qualify for this discount. If Agent is another static type in the Application then the signature of the method to calculateDiscount( Customer argcust) is defined with an argument of type Customer. So only Customer objects can be passed as parameters.

Now suppose the application is dealing primarily with dynamic types and assume both Customer and Agent classes do not exist instead we use a class called DataObject to encapsulate data. Now that same method will be defined as calculateDiscount( DataObject argcust) .
Both Customer objects and Agent Objects appear to the application developer as DataObjects(the generic container for data). Now it is upto the developer to ensure that he does not inject a dataObject with the state of an Agent and pass it into the calculateDiscount() method. Even if he does, the compiler will not complain and will result in an runtime application bug.

The important question that an arise in your mind at this point is why go through all the pain of using dynamic types when you acheive it with static typing. True - Dynamic typing introduces a problem of lack of type safety. But it does provide certain benefits and moreover there are situations where you do not need static types at all. Those situations are characterized by the use static java beans with only state and very little behavior. Classes in the domain model immediately do not fall into this category since domain models primarily are designed around behavior. But there are many layers within an application that are essentially best suited to dynamic types. The use of static type in these situations results is unwanted coupling and also more development effort in creation and maintenance.

Some of the layers are
a) edge data parsing - either from the network or from files. XML & fixed width parsing included does not require static types.

b) Application Config Information - is fundamentally dynamic in definition.

c) Relational Data Managers - That reads data from RDBMS.

Further, it is far more powerful to use codegen or bytecode manipulation to generate static types from Dynamic type objects based on some type definition (XML Config). This layer then becomes a data mediator service between the world of static and dynamic types.

Handling time variant data

Consider a rate or price feed - all bankers and energy traders have to deal with this regularly.

Basically there is a set of values (the price or the rate) for a specific commodity / index / currency from a specific data source.
Now you can have values for a year, which may be further qualified by values for every month, that is again qualified by values for each day in the month - which is again qualified by values for every hour for that day and so on....(it depends on the business domain or the commodity or even on the customer) . We (developers) should not assume the precision of the time spread.

The problem is

1. How do I abstract this price information or rate information in such a way the clients can access aggregate (or summarized) values without really being concerned whether detail values (more precise) exist or not.
For example a price feed provided you hourly prices for this month, but only monthly prices for months beyond this month, only quarterly prices for the months beyond 6 months and yearly prices for anything further.
Assume today is Apr 01 1004 . How do I access the price from the abstraction for
a) April 01 2004 14:00:35
b) April 02 2004 13:00:00
c) May 05 2004
d) October 10 2004
e) April 01 2005

It means that is a specific (detail) price exist use that otherwise use the next summarized price.

I am thinking about a tree where each Node has aggregate properties based on the properties of the child nodes. Each nod then becomes a collection whose individual properties are aggregate values form the child nodes.

A DAY Node has a price property - which is the average (on type of aggregation) of the price of all its HOUR Child Nodes.
Another DAY Node does not have children at all (any specifics) - in that case the price is a fixed (allotted) price and not an aggregate price.