Machine Reasonable Design

Let’s think about the 3 broad categories of persons involved in creating and running a venue (again, we use venues are examples but this message carries across all typical financial systems):

Business – sales and product managers tasked with designing features that would be attractive to clients (i.e. can be sold)

– sales and product managers tasked with designing features that would be attractive to clients (i.e. can be sold) Developers – project managers, actual developers writing the code and quality assurance personnel (QA)

– project managers, actual developers writing the code and quality assurance personnel (QA) Regulators – compliance staff and the actual regulators

Currently these three groups communicate with each other over long Word documents and email chains. Such ambiguity leads to missed requirements, their inconsistency and poor code quality (when it’s actually delivered). Poor code quality results in more Word documents, emails and middle management/compliance headcount. This leads to internal politics and makes everyone depressed. Depressed people cannot be motivated, so the bank makes less money. And so it continues.

When you think about the unfathomable costs of software development in finance, this is the reason. Finance has enough smart people that know how to code, figuring out what they should code is the difficult part. Very few people realise this. This is analogous to how most people think they’re better drivers than the average. Telling developers, people that were the smartest in their High School class, that they need to think more about what they’re going to code before they start coding is a challenge. However the payoff is worth it.

One analogy that we often is use is that of a skyscraper construction process. It’s similar to finance in that it’s very complex and involves different types of stakeholders: from architects to civil engineers to construction workers. What’s different is that they communicate over something that’s precise – a blueprint that describes in necessary detail what should be built.

Finance needs something similar and it has to be incremental - it cannot require firms to wait years before any results start to bear fruit.

The Promised Land

Financial systems should have precise designs – especially in environments with so many moving parts and stakeholders. Understanding the full behaviour of a system – i.e. all the infinitely many ways it can behave – before you start building it sounds like a trivial requirement, but it is far from the norm. There are two culprits behind this: finance, until recently, was making too much money to care and the technology/science wasn’t there to facilitate this.

In other safety-critical industries Model-Based Engineering (MBE) is advocated as a way to ensure rigour of software development processes. There are numerous tools like MathWorks Simulink that allow one to construct and reason about data-flow models (e.g. for control algorithms in avionics). But these are very different from the typical systems in finance. Finance deals with FIX messages, derivative contracts, etc. Simulink and similar tools would be too difficult to adapt to financial markets.

The design of a financial system in this case is an executable model of the system business logic (together with messaging, etc) with which you can:

Compile the model to binary or generate source code in a target language

Verify properties about its behaviour

Generate test cases

Generate English-prose documentation

Run an audit against the actual production trading data.

Why is it Machine Reasonable and why is this important?

A typical financial system is complex and more importantly, it may be in a virtually infinite number of states. Just as 80 or so years ago people started to use computers to reason about numbers (because the calculations became too intense for humans to perform ‘by hand’), so must we when it comes to reasoning about algorithms. After all, just as numbers, algorithms are mathematical objects. If you think it’s a good idea to use a computer to price an option or forecast price of a security, you should also try using it to analyse algorithms. You’ll be surprised.

By Machine Reasonable we mean that you can use a computer to automatically analyse behaviour of this code and ask typical questions which may cover infinitely many possibilities. We’ve already written about Machine Reasonable APIs for specifying how systems should communicate with each other. This post tackles a different problem. One example: “Can this venue product fills outside the NBBO?”. You simply cannot test (in a traditional way) for these properties. Once you are confident the design is correct (or still correct when you make amendments), then you leverage it to test all of the edge case (we call these state space regions) and use it to audit production data.

Automated Reasoning with Imandra

Historically, reasoning about code in the deep way we’ve been discussing was very labour-intensive (limited automation) and reserved to a few that had specialised training (e.g. teams of scientists at places like NASA). We created Aesthetic Integration to change this.

We’ve spent over 4 years of R&D to create an engine that allows you to write production quality code and also reason about its behaviour. Check out https://try.imandra.ai. We’re launching a commercial version this September that you’ll be able to download and use on your local files, seamlessly leveraging Imandra’s groundbreaking scalable symbolic AI in the cloud.

We’ve taken a pure subset of OCaml and given it mechanised formal semantics – meaning that everything you write in this language, Imandra automatically translates into mathematical logic. The beauty is that you can leverage the OCaml ecosystem (e.g. compiler, etc) to develop code and use Imandra’s Reasoning as a Service (TM) engine to verify its critical components.

Imandra has two core features:

Code Verification – ensuring the code satisfies a certain property (and getting a mathematical proof when it does or a concrete counterexample when it doesn’t). Imandra’s code verification is built on major recent advances in the field of formal verification. We’ll see examples of this later when we look at the UBS Form ATS and transitivity of their order ranking logic.

– ensuring the code satisfies a certain property (and getting a mathematical proof when it does or a concrete counterexample when it doesn’t). Imandra’s code verification is built on major recent advances in the field of formal verification. We’ll see examples of this later when we look at the UBS Form ATS and transitivity of their order ranking logic. Code Analysis – understanding the different ways the code may behave. We already discussed that there are typically infinitely many possible states – this feature describes them symbolically through a finite number of edge cases (or state space regions).

Both of these are important when it comes to creating and using Machine Reasonable Design.

When one claims that a venue, for example, “Always generates fills within the BBO.”, you’re covering infinitely many scenarios. You’re not forced to come up with some sample inputs that would pass for ‘test cases’, you’re allowed to reason on a higher level, just like you do when you speak to someone describing how this venue works.