A new paper suggests that shared source code can help deliver an efficient and best of breed “last mile”
check for automated trading systems. Colin Lambert takes a look and talks to the author.
It can hardly be said that operational checks around automated
trading have been a low key issue. Regulators around the
world are delivering rules for market participants and,
occasionally, the industry is pushing back as the new framework
is thrashed out under the scope of MiFID II and Reg AT.
That said, the issue seems to run into a brick wall when
looked at from a broader perspective. Companies jealously
protect their source code, even if it is, on occasions, aimed at
regulatory compliance and as such, less open to innovation
A recent paper from eCo Financial Technology seeks to take
the discussion around risk controls further – and into the bargain
bring the industry closer together – by looking at the possibility of
shared source code around the “last mile” or “edge” check.
“We are trying to increase the volume of debate around
community sourced software,” explains Ian Green, founder and
CEO of eCo Financial.“There has been a lot of interest around
regulatory compliance – those demands are most robustly met
by taking a step back and identifying best practice in each
The last mile check is part of the control logic, an
independent failsafe representing one last check that the order
being put into the market is appropriate and meets a set of
parameters. The eCo paper notes that regulators are becoming
more focused on not only what risk controls are in place
around the trading programme, but also on how controls are
developed, deployed and maintained.
The paper stresses that all automated trading firms have
controls in place, however it also observes that these are not
easy to maintain, and can be flawed in several ways. For
example, the control logic can be implemented in the same code
line as the trading system, which offers efficiency but does not
represent an independent check. Equally, the timing of the
check, potential latency in the process, and potential bugs in the
programme all offer the opportunity for something to go wrong.
There is also the matter of ensuring that the firm has risk checks
that span all relevant trading venues. “Single venue checks such
as checks provided by trading venues themselves do not logically
suffice, even if they are collated after execution,” the paper states.
Rule gaps also raise the risk levels as does having too many
rules. “A problem is that firms are not looking at this issue from
the top down,” explains Green. “They are all meeting the
regulators and explaining how their controls work, but these
controls are all different and we end up with an overly complex
rule set that is hard to manage and control.
“There is not and should not be, a competitive edge in how
you check whether a trade should go through or not,” he
stresses. “But at the moment the industry is showing a lot of
different faces to the regulators, which is confusing the issue
unnecessarily. There is a lot of value in creating a clean and
effective rule set for last mile checks; there would be much
more value if a number of firms developed it in collaboration.”
The paper lays out what eCo Financial considers a “good”
control environment, stressing that it has to be comprehensive,
with the last mile check on the periphery of the trading firm’s
architecture checking every trade or order before it is
submitted. The firm also says that the last mile check should
take one or two micro-seconds, in order not to impact on the
firm’s trading performance and it should be independent.
A real time view of positions across trading venues is also
vital for the last mile check to perform, as is a clearly defined
rule set that describes its logic. The control environment must
be clearly and well governed as well as fully tested. It should
also be configurable to enable the last mile check to react
differently according to a given and flexible set of parameters
such as the dealer concerned or the market being traded. The
framework should be documented, monitored and efficient,
with some checks that do not directly impact live trading being
controlled in a separate environment.
A Unified Approach?
The paper argues the last mile check, especially given how it
should be independent of the trading architecture, offers opportunity for industry collaboration. It notes that all firms share
the same requirement to avoid errors and says that none of them
want to see market participants go out of business due to
disastrous e-trading losses, such as happened at Knight Capital.
It is of course, more complex than delivering one set of rules,
as Green points out. “Different market structures demand
different controls,” he says. “One firm could, for example be
very good in fixed income, but less strong in FX options. As
things stand they are running a risk that their control function
breaks down in FX options, which could cost them hundreds of
millions of dollars, and then stop them trading in fixed income
where their controls are excellent.
“With a collaborative approach participants can agree one
set of rules for each market structure and share those, it will
lead to better outcomes,” he continues. “There is the added
benefit of more sets of eyes looking at the code, this should
help find any coding errors.”
The paper asserts that addressing error-avoidance robustly is
both difficult and expensive. “Since it doesn’t affect what
trades are placed or what business a firm chooses to engage
in, there is no intrinsic proprietary advantage in building a
custom solution. Indeed, it is to the advantage of everyone to
agree on a rule set for a last mile check. Not only would this
attain a “wisdom of crowds” benefit from the scrutiny of many
parties, it could also be expected to improve the quality of
discussion with regulators.”
As to the form this cooperation can take, the paper
acknowledges that the starting point is agreeing on a rule set
as a written specification for automated trading systems,
however, it claims that such a step only covers two of the eight
issues it cites as potential control risks.
“A more meaningful and ambitious level of collaboration
would be sharing a ‘community source code implementation of
the last mile check,” eCo Financial states. “This would be far
more powerful, potentially addressing all eight of the common
failures. Such an implementation could be integrated into each
firm’s own configuration, messaging and event infrastructure.
“For firms that use third party software the shared last mile
check could be adopted by the software providers and
integrated into their own systems,” it adds.
The paper does note that one further level of collaboration
could be achieved by creating a utility to run a last mile check
on behalf of the collaborating firms. “While this offers benefits
over and above sharing source code amongst the community of
participants, it also brings new issues of data security, legal
liability and constant critical dependence upon the utility
owner,” eCo says. “Furthermore, all firms using such a utility
must be able to prove that its operation is sufficiently closely
under their control that they can fully meet strong regulatory
diligence standards without reliance on representations from
the technology provider.”
Getting it Done
The big challenge for such a proposal is, as always, actually
getting enough people in a (metaphorical) room together to
deliver critical mass – and this is exacerbated in this case by
the diverse nature of those likely to be involved if such a
venture is to succeed.
The paper acknowledges that successes in this area have
been “few and far between” and that, “The same factors that
have impeded the realisation of very many other collaboration
plays stand in the way of this one too.”
It also observes that one of the factors that has impeded the
realisation of many collaboration plays is a “natural tendency
to reach directly for the most beneficial possible outcome”.
this case, the utility is the most beneficial option, however, “We
also saw that it is the most heroic venture, which, like
community source code sharing, requires agreeing on every
point of specification – almost certainly without the
illuminating ability to inspect the code that implements it – as
well as tackling several other kinds of issue (data security,
liability, business dependency) at the same time.
“Community code sharing, while simpler, has rarely been
tried,” the paper continues. “Partly, this is due to issues of trust
in the quality and portability of another firm’s code; concerns
about support; and the lack of standardised commercial and
legal terms for such a transaction.
“Beyond this, there are cultural factors arising from the
ingrained disposition of leading firms to develop their own
software and of smaller firms to license systems from
established vendors, it adds.
That said, the paper argues that in the case of community
source code some of these arguments against are “less
While it is natural to look for differential advantage in
proprietary trading logic, the dominating requirement of an
edge check is logical and technical soundness. “Here, having
code-level scrutiny from peer firms is a plus rather than a
minus,” the paper asserts.
The paper also notes that in some functional areas it can be
hard to identify a code line in use at a relevant institution that
can be transplanted conveniently to other firms, but points out
there are top quality implementations of last mile checks
available in commercial community source form through eCo
And while the paper says that often a bank will, correctly,
strongly favour the re-use of componentry from its own IT stack
rather than sourcing equivalent code from elsewhere, in the
case of a last mile check there is a positive advantage to using
code developed independently from the trading software.
The final argument in favour of community source code is
that while software that comes from third parties is sometimes
perceived to have a higher total cost of ownership than
software that a firm can develop for itself, especially if it can
leverage its existing componentry, in eCo’s view, few, if any,
firms could safely deliver a fully satisfactory solution for edge
checking on terms that are favourable to licensing a top quality
implementation from elsewhere.
“Moreover, even if the in-house
development costs were zero, when the price of failure
can run into the millions, tens of millions or hundreds of
millions of US dollars, the prudential benefit of a community
source solution is compelling,” it adds.
Part of the problem facing the industry in achieving
consensus is that, as Green puts it, the issue is technically very
interesting, and as such people want to do the work
That said, he is hopeful that the arguments
presented by the paper will succeed. “This is as much an
economic argument as a technical one,” he acknowledges.
“The industry can produce a better outcome for less cost if it
adopts community source code. eCo Financial was established
for just this type of situation and we have suitable tools to
evaluate the code when required. In reality, the first priority is
to clarify exactly what is being claimed of it.
“There are challenges around getting people from different
sides of the industry into one room,” he continues. “It will also
help when the current debate in many institutions about
whether and how they want to be in the trading business is
settled – we need that commitment and stability to succeed.
“Notwithstanding that, we are heartened that there is
genuine appetite to push ahead. The last mile check is a great
example of where community source code can help provide
superior protection from errors, in a dynamic environment
where best-of-breed is always available, and at a lower cost.”