Scope, Scale and Single-Dealer Platforms: Jon Healey on a Career at the Cutting Edge of FX

Introduction

In this episode of Caplin Connects, John Ashworth, Chairman of Caplin, speaks with Jon Healey, a technology leader whose career runs through more than three decades in financial markets, much of it at the heart of electronic FX. Jon did not arrive by way of the trading floor. He began as a programmer, writing COBOL for a company that manufactured cardboard for the building industry, before high interest rates in the 1980s and the pull of the City drew him into asset management, then corporate treasury, and in time the banks where he built the electronic FX capability that came to define his career.

The career curve is unusual. Seven years running the in-house bank at Tate & Lyle, thirteen years at HSBC Midland through the birth of the single-dealer platform, then shorter, more concentrated builds at Lloyds and BBVA. What emerges is less a tour of firms and platforms than an account of the disciplines that make technology delivery succeed: managing scope, knowing when to build and when to buy, designing systems that can be changed, and keeping relationships honest on both sides.

A Lesson in Code, Learned Early

The discipline that shaped everything else arrived in an unglamorous setting. In an early role at an asset manager, writing capital gains code in BASIC, Jon learned what happens when code is allowed to branch without control: each time a bug is fixed, the fix must be repeated across every branch, and the cost multiplies quietly and never stops. It is the software equivalent of keeping several slightly different copies of the same contract; change one clause and you must remember to change all of them, or live with the one you missed.

That lesson set his standard for what good technology looks like: "the highest quality is going to come from something that is simple, straightforward, easy to manage."

“The highest quality is going to come from something that is simple, straightforward, easy to manage."
‍
^{JON HEALEY}

‍

When the Internet Became a Distribution Model

By the time Jon joined HSBC Midland in the mid-1990s, electronic FX already existed in a recognisable form. EBS and Reuters dominated interbank matching, polarised between them by currency; the bank itself had run an electronic trading platform since the early 1990s, built on BBC Micros and reached over leased lines. The concept of trading on a screen was well understood. What changed everything was the economics of reaching clients, rather than the idea itself.

The internet turned distribution from an expensive, large-client proposition into something that could reach almost anyone for very little. Once that was clear, the strategic conclusion followed quickly, and defensively: "If we've thought of this, then so has everyone else, and so therefore we better be in a position to be able to deploy one of these things as soon as we can, in order to defend against potential competition." The priority was to protect the corporate base, where the profit sat, before a new entrant could reach it first.

The first client-facing platform reflected the same clarity of purpose. It was aimed squarely at corporates, request-for-quote only, and designed to remove any ambiguity about who was buying, who was selling, the value date and the amounts. The front end, bought from a third party, was the smallest part of the work; the pricing, credit and deal-processing engines, all built in house, were far larger.

‍

‍

Build, Buy and a Single Way In

The build-versus-buy question returned at every stage, and his answer changed as the market matured. At HSBC the bank bought a front end and built the engines, because nothing worth buying existed for the harder parts. At Lloyds, brought in to signal the bank's wider ambitions, he built a streaming platform called Arena in a two-year sprint, again because the market offered little to buy. At BBVA, a near-greenfield opportunity, he built a pricing and trading engine and a credit engine once more.

What held these decisions together was an architectural principle he applied from the outset, and it is the one that later made buying possible: "Everything should go through the API, and if you can't change the front end at will, then the design's wrong." A single entrance into the system meant the front end was never load-bearing in a way that trapped the bank. When the technology to buy one finally matured, the logic was simple: "Why maintain something that you've built at a fairly significant cost when actually you can outsource that to something else? Because the technology was now there."

“Everything should go through the API, and if you can't change the front end at will, then the design's wrong."
‍
^{JON HEALEY}

‍

That reasoning eventually led BBVA to replace its front end with Caplin's. Notably, Jon removed himself from the vendor selection process: given that he knew John Ashworth personally, he handed the requirements and a gap analysis to his team so that no one could suggest he had influenced the outcome. Several platforms were assessed; the team returned to Caplin.

‍

The Discipline of Scope

If one theme runs deepest, it is scope. Jon traces his wariness to the internet bubble, when every project attracted a chorus of "we could do this" and "we could do that." His response was, and remained, orthodox project management: "Let's get the scope defined and let's stick to it." Scope creep is the phrase he came to know best.

The same instinct governed how he treated vendors. Where many clients push for endless custom features, he was, in John Ashworth's words, "absolutely brutal" about not allowing his people to ask for them. This was not obstruction; it protected the vendor's ability to maintain a clean product and the bank from painful upgrades alike. It connects to a hard-won view about features, formed while adding function after function to Arena at Lloyds: "You can put all sorts of bells and whistles around your platform, but how many of them are actually useful? How many of them are actually going to get used?" Corporates have a business to run; the test is value delivered, not capability displayed.

Relationships That Work Both Ways

Jon's philosophy of vendor relationships has an identifiable origin. At Tate & Lyle, the treasury maintained a matrix that measured the value of each banking relationship to both sides at once - the value to the company and the value to the bank - and used it to decide how many banks to keep and for which strengths. That habit of weighing both sides never left him.

"Any relationship has to benefit both parties, and if it doesn't, then one of the parties is going to be dissatisfied and leave eventually." He is candid that the balance need not be equal: "Ideally, more benefit to you than them, but there still has to be some benefit to them." The same logic shaped how he thought about custom development. Anything genuinely differentiating, he preferred to build himself: "If it is something that I need because it's a differentiator, then I want it to be a differentiator and not something that you can then sell on to all your other clients."

“Any relationship has to benefit both parties, and if it doesn't, then one of the parties is going to be dissatisfied and leave eventually."
‍
^{JON HEALEY}

‍

The through-line extends to colleagues as much as counterparties. Several of his moves followed the same people from firm to firm, culminating in the group reassembling at BBVA. As he puts it, "It's not so much what you work on, it's who you work with."

Where AI Earns Its Place, and Where It Waits

Asked what he would and would not do with AI, Jon is expansive on one side and cautious on the other. "There is almost nothing that I wouldn't be doing with AI," he says, before locating the value precisely: pricing analytics, working out "the best source of pricing for the flow that you're seeing" and "the best execution venues for the flow that you're receiving," then predicting elements of incoming flow and pre-positioning accordingly.

“There is almost nothing that I wouldn't be doing with AI."
‍
^{JON HEALEY}

‍

These are not new questions. In HSBC's early days, parsing dealer chat raised the same temptation: whether the pattern of clients asking for prices and not dealing could be used to infer their intentions and skew accordingly. It was governed then by judgment; a head of sales for whom ethics was a first principle ruled it out. The possibilities AI opens in FX are extensions of questions the market has faced since electronic trading began, and they still require someone to decide what is acceptable.

On the technology build itself he is measured. He has noticed developers becoming, in effect, reviewers of AI-generated code rather than authors of it, and is "somewhat dubious" that this removes the need for expertise; getting good results still depends on knowing which model to use and how to work with it, so "the requirement for having super smart developers is still there."

On the thorny question of legacy code he is deliberately unfashionable. Rewriting code that works is, for him, close to the last thing he would spend finite resources on. The judgment is one of priorities: analytics that improve pricing and flow management will almost always repay the investment more than reworking a function that is quietly doing its job.

‍

Think Temperament Not Technology

FINAL THOUGHTS

Across four decades and several rebuilds of essentially the same system, the constant is a temperament rather than a technology: define what you are doing, keep it simple enough to maintain, make sure both sides of every relationship gain something, and spend effort where it changes the outcome.His closing reflection could stand for the whole conversation, and as a caution for an industry now tempted to rebuild everything at once: "If something is working and it appears to be okay, it probably is okay, and so therefore I wouldn't bother with that. I'd be much more interested in adding value in other places."

“If something is working and it appears to be okay, it probably is okay...I'd be much more interested in adding value in other places."
‍
^{JON HEALEY}

‍

Follow Up

Connect with Jon on LinkedIn

Follow Caplin on LinkedIn