In these times of financial woe, people love to complain about all the big, nasty, faceless companies avoiding paying tax. They inevitably moan about it on Facebook, Google and Twitter (and sometimes even do something about it in the real, physical, world). But what about those companies themselves? The Web 2.0 behemoths are now some of the largest companies in the world, and they’ve decided – just like the evil old companies – that they don’t like paying all that tax. Don’t be evil… and don’t pay any tax if you can help it. But how do they do it?

The Numbers

An Irish Times newspaper article caught my eye the other day. It discusses the rapid growth of Facebook’s Dublin operation in 2010, whose accounts have just been published (as they must be by law, despite FB’s apparent reluctance). The headline figure is that:

[Revenue] is up from €15.2 million to €229.1 million

That’s a pretty significant increase! But that’s only revenue, how much of it was left over as profit?

Facebook Ireland generated a pretax profit of €1.9 million

What?! Where did the other €227 million go?

According to the article it mostly disappeared into a mysterious black hole known as “administrative expenses”:

Administrative expenses increased … to €221.6 million as a result of … royalties paid to other Facebook entities for services provided during the year.

How do they do that?

Is it me or does that sound suspicious? Well, it should do, because it is.

It turns out that Ireland’s significantly lower rate of corporation tax (12% vs 26% in the UK, and one of the lowest in the world) isn’t the only reason why companies like Facebook, Google et al move there. There’s also the very useful fact that, unlike most developed economies, Ireland chose not to introduce any legislation to prevent companies siphoning off their revenue to low-or-no-tax regimes like the Cayman islands or Bermuda.

So that’s where the “missing” €221 million has ended up: it’s been paid from the Irish part of the business to the tax-haven subsidiary, leaving only a small amount subject to corporation tax in Ireland. This practise is known in tax circles as the “double Irish”, and it (along with its Dutch equivalent) seems to be fairly widely used and well understood, even having its own wikipedia entry. Of course Facebook now funnels as much as possible of the revenue from the UK (its second biggest market) through the Ireland operation to get the most out of this arrangement. That explains the large increase in the numbers since last year.

There are many high-profile tech companies that have Dublin operations and may be avoiding tax in this way, including:

• Facebook
• Twitter
• LinkedIn
• Google
• Microsoft
• Oracle

That’s quite a roll call.

The Result

The result of all these shenanigans for Facebook? It pays a ridiculously small effective tax rate of less than 1%, even better than Google’s 2.4% rate. And given Ireland’s current economic state I can’t imagine their government will be introducing more restrictive tax legislation any time soon in an attempt to crack down on it. They can’t risk these big companies abandoning their new homes in Dublin’s Silicon Dock.

Of course, you should feel free to ‘like’ this blog post on Facebook, after all, what will it cost you?

(* Disclaimer: These are solely my opinions, not those of my employer or anyone else).

Discriminated unions are one of those things in the lexicon of functional programming that can often sound baffling to “outsiders”; it’s almost up there with monads and currying. But in practice they’re simple and incredibly useful. I thought I’d try and show a concrete example of where they can be used in a way which is more powerful and robust than the equivalent OO approach.

The usual suspects

When people first start looking at functional programming, they often come across examples that implement a compiler, and this is their first exposure to discriminated unions. Unfortunately these examples tend to use complex recursive discriminated unions to represent the language syntax tree, which can be a bit of turn-off for anyone who’s not a language geek.

A problem

The way I like to think of DUs is a means of easily and precisely specifying a set of types that we’re expecting to work with.

What do I mean by this? Well, imagine you’re writing some code that can work on various different types, and you need to identify some common aspect to identify them. For example, you’re valuing different financial product types: swaps, swaptions, caps and floors. Although each of these trade types would be represented differently, you may want to perform the same operation across all of them.

The OO approach

The normal OO approach would be to use an interface; implemented by all of the types and consumed by our method. For instance:

class Swap : public IValuable { ... }
class Swaption : public IValuable { ... }
...
public double ValueTrades(IValuable[] trades) { ... }

But this isn’t particularly elegant or easy. For a start it requires that the type implement the interface – what if you’re working with externally provided types that can’t be changed? The other thing is that interfaces tend to give you a false sense of security about type safety. Given that we know there’s an object implementing the interface, I’ve all too often seen OO code taking an interface parameter then immediately type-casting it to another interface that the underlying object is expected to support. Run-time typing failures FTL.

The union

So how could we implement this using discriminated unions instead?

type Trade = 
    | SwapTrade of Swap
    | SwaptionTrade of Swaption

What we’ve done is create a new type that consists of exactly one of its possible cases. We identify each case with a tag (in fact, these types are often called tagged unions) called SwapTrade and SwaptionTrade and separate them with the bar ‘|’.

Easy, isn’t it? But, err, how do we get to the actual thing we want? Well that’s where another functional programming staple steps in: pattern matching. We can add some code that will match against the possible union cases and allow us to get at the type itself:

let valueTrades (trades : Trade list) = ...
    trades |> List.iter (fun t ->
        match t with 
        | SwapTrade s -> (* do something with s *) () 
        | SwaptionTrade st -> (* do something with st, which is of type Swaption *) ()
        )

Pattern matching warning

Hope you found this useful. As a long-term OO developer moving to functional programming it certainly helps me to see how aspects of FP can be applied to common OO problems.

I’m making use of a few F#/.NET idioms to make the process easier. For instance, sequences (.NET’s IEnumerable) are used as the source of uniformly distributed random numbers. Also, to verify that the resulting numbers are actually normally distributed, we can easily use existing WPF/silverlight controls to visualise the values direct from within Visual Studio, in a manner similar to this previous post – but without having to write the plotting code ourselves.

Implementation

So firstly, we create the random number stream:

let rr = System.Random(System.DateTime.Now.Minute)
let rands = seq { while true do yield rr.NextDouble() }

As you can see rands is an infinite sequence. As such, you should be wary of the “eager” functions from the Seq module that attempt to consume the entire sequence at once, they’ll obviously cause a problem here. Also notice that I’ve picked a somewhat dubious seed for the random number generator, as this is only for demonstration purposes.

In order to obtain normally distributed random numbers I’m using the Box-Muller transform. I started off with an implementation transcribed from VBA (from Wilmott et al) – yes, yes, I know – but of course this used mutable references. Not nice. So I reworked it a little to use Seq.pick, which takes items from the sequence while a predicate returns None:

let boxMuller _ =
    let (x,dist) = 
        rands
        |> Seq.pick (fun x ->
            let x = 2.0 * x - 1.0
            let y = 2.0 * ((Seq.take 1 rands) |> Seq.hd) - 1.0
            match (x * x + y * y) with
                | dist when dist < 1.0 -> Some (x,dist)
                | dist -> None
            ) 
    x * Math.Sqrt(-2.0 * Math.Log(dist) / dist)

It’s not particularly efficient as we’re consuming two uniform numbers to generate one normal one – hence the additional Seq.take within the pick. Of course we could change the function to return the 2 generated numbers as an extra element in the tuple.

Next, let’s generate some numbers, and get them in a suitable form to display:

let makeData _ =
    Seq.init 100000 boxMuller
    |> Seq.countBy (fun d -> 
        let d = decimal d
        Math.Round(d, 1))
    |> Seq.sortBy fst

We initialise a sequence with an arbitrary amount of numbers (100000, enough to get a good distribution, hopefully), then use Seq.countBy to do a naive grouping that allows us to see how the numbers are distributed, i.e. counting how many numbers fit in each 0.10 bucket. We then sort the output by bucket.

Visualisation

Now we can display what we’ve got. We can create a simple WPF object-model using imperative code, including the very useful chart control from the WpfToolkit. The chart control enables us to add a series and set our seq<decimal * float> directly as the series ItemsSource, which is the standard way to specify the items for a collection control. If you specify the tuple Item1 and Item2 properties for the bindings, WPF will be able to access the data from each element, and that’s all you need.

    let series = 
        ColumnSeries(
            IndependentValueBinding = Data.Binding("Item1"),
            DependentValueBinding = Data.Binding("Item2"),
            ItemsSource = makeData ())
    let chart = Chart()
    chart.Series.Add series
    Window(
        Name="Plot",
        Title="Normally distributed random numbers",
        Width=900.0,
        Height=700.0,
        Content=chart,
        Visibility=Visibility.Visible)

Here’s the resulting output:
As I’ve mentioned before, this is a fantastically immediate way of doing numerical development in Visual Studio. You can enter all of this code directly into F# interactive within VS, iterate, and quickly see the effect that your changes have. It’s just as interactive as using the graph features in Excel, and the resulting code is much more easily reusable.

XD5RRV3XDNHN

I heart spreadsheets

Unfortunately, given the ever-increasing focus on accountability and scalability in these domains, Excel is also an increasingly inappropriate platform for delivery of this sort of functionality. How can organisations ease the transition away from this environment to something more easily manageable, while retaining it’s positive benefits?

Disclaimer: These are my own views and not those of my employer. The scenarios I describe are fictitious and not based on actual practices at my place of employment. Any similarity to actual events and behaviours is coincidental.

I see two main aspects of Excel’s operation that prove valuable in general, and in finance in particular: visibility and immediacy.

Visibility

From an end user’s point of view, one of the most positive aspects of Excel is it’s transparency. Even in an environment where complex processing goes on inside a plugin – say, an Excel user defined function (UDF) packaged as an XLL – it’s still only in the scope of a single function call in a single cell. You continue to get good visibility of the inputs and outputs from the function.

You can also get a good higher-level view of how the different parts of the calculation fit together. Either by inspection, editing the formula to quickly see which cells it references, or by using the formula auditing toolbar to get an overlay of dependent and precedent functions, you can see roughly how various parts of the calculation fit together.

This, combined with the logical separation of functionality into separate worksheets, gives you the impression of understandability.

The problem is that it’s just that – an impression – there is no structure enforced by the worksheet separation, you’re free to link between them as you see fit, and this can result in an extremely complex and virtually indecipherable “flow” of calculation within a workbook.

Immediacy

Luckily, to offset the complexity we have another important aspect of Excel’s usability: it’s immediacy.

Trading users can very quickly modify calculation trees to perform ad-hoc additional calculations such as applying spreads, and to gauge the effect of market moves on their portfolio, i.e. “what-if” scenarios.

Structuring users can fairly easily – given an existing set of functional pieces – assemble a model to price a complex new trade type. Although this is a much less common use case now that the demand for getting new structured products to market quickly has essentially vanished.

As well as this type of gross modification, it’s also possible to just repeatedly re-evaluate some small part of the calculation to quickly determine how it is affected by other changes.

The immediacy of the Excel environment, combined with the use of the Visual Basic for Applications (VBA) scripting language, enables both business and IT users to rapidly build out new sheets to perform ad-hoc tasks. Rapid application development, or RAD as it’s known, is all well and good for performing some transient, ad-hoc calculation for limited use, but unfortunately these tools have the habit of becoming indispensable parts of an organisation’s workflow. That’s when you start to see serious problems with scalability and maintainability.

The problem?

So the fundamental tension here is that exactly the same features which make Excel useful to traders, structurers, etc., also make it highly unsuitable for use in these environments. You really don’t want traders to be able to subtley alter the flow of the calculation, as much as they might like to. Excel should really be a read-only view on some underlying trade data source and calculation engine, but this isn’t always how it’s implemented.

You also want to provide some flexibility – the ability to experiment, explore and examine – but within certain constraints and without compromising future requirements. Being able to price a trade is a good start, but you will subsequently need to book it easily, re-value it reliably and potentially risk manage a large portfolio of them.

Moving away from Excel

Many houses provide underlying quant analytics implemented in C++, with a native C++ interface and a variety of other (sometimes auto-generated) wrappers that make it accessible in other environments. Ideally, the amount of actual functionality in these wrapper layers should be kept to an absolute minimum. It should be commodity code that can be regenerated as and when required.

However, even if this is the case, unless you have the ability in the underlying code to fan-out the processing you will still be constrained by the operating system process limits, e.g. 4gb address space.

The common alternative to hosting pricing and risk management within Excel is to write new dedicated applications to perform the calculations and (hopefully) provide a means to inspect and troubleshoot it.

Unfortunately these systems are built by teams who aren’t particularly familiar with the way the front office uses Excel. It’s often the case that spreadsheet development teams and systems development teams don’t interact; the former tend to be based on the trading desk while the latter are in another part of the building.

So the end result can end up being systems that work in a way developers feel comfortable with, rather than the way business users would like them to work. This can make the system seem like a black box to it’s users. And to make it worse these are the users who are accustomed to Excel’s high levels of transparency.

Although the system may be enforcing the fact that trade value is strictly a function of the trade, market and static data, having some transparency can still be valuable in giving skilled users confidence in the underlying calculation. They can apply their not-inconsiderable intuitive abilities to quickly gauge the correctness or otherwise of the valuation. It can help the quants move away from their native Excel/Matlab-style iterative development environment. And when groups need to work together to reconcile differences, everyone can benefit.

The problem? This amount of transparency has to be built into the system or the quant library pretty much from the ground up.

Solutions

One possible approach is to make your system a general purpose calculation engine. This has some appeal, but you have to be careful about sacrificing performance for generality. You might be tempted to try exactly matching the semantics of Excel’s calculation and type system. This can be a nightmare, with all sorts of limitations and nasty edge cases. For example, the fact that errors are a simple numeric value with no facility to carry extra information is crippling, and also the lack of support for objects as first class values in the type system.

However you choose to implement your calculation engine, ensure that it’s loosely coupled enough to be run out-of-process or across machine boundaries without code changes.

Here are some bullet-point takeaways for easing the transition:

1. Provide a means for users to examine intermediate calculations, and surface it in the UI.
   This will give your intermediate and end users confidence in the calculations
2. Provide a means to capture and re-play valuations, including all their inputs and outputs.
   This will assist in reconciling valuations, and in passing snapshots around between groups.
3. Provide the ability to drive the system programatically.
   Along with persistent valuations, this will help in regression testing

I hope this post has served to give you some insights into the potential challenges of moving users away from Excel into more robust systems, why some of those users may be reluctant to move, and how you can help to ease the transition. And of course, let me know via the comments if you’ve got any observations on the subject.