Two places called DVL: AI adoption in wealth management starts with knowing what your firm means

21 hours ago

12 min read

Week five of Beyond the Hype, a 12-week series from our CEO Charlie Symonds on what modern technology practically means for wealth managers and providers across financial services.

At 08:32 on the morning of Monday 28 August 2023, a bank holiday, a flight plan arrived at the UK's air traffic control system for a Los Angeles to Paris service that would cross British airspace later that day. It was a perfectly valid plan. Every waypoint in it was real. [1]

Two of them had the same name.

The identifier DVL referred, in one part of the route, to Devils Lake in the northern United States, and in another to Deauville on the Normandy coast, about 4,000 nautical miles away. Both are legitimate, both are outside UK airspace, and the international flight plan format allows the same three letters to be reused in different parts of the world. The system searched forward for the point where the aircraft would leave British airspace, matched the wrong DVL, and found it could not build a sensible route between its entry and exit points. It raised a critical exception and stopped. The backup system received the same plan, applied the same logic and stopped too. The whole sequence took less than twenty seconds. [1]

Two places called DVL, about 4,000 nautical miles apart

Sunlit Devils Lake water tower beside houses and railroad tracks under dramatic blue storm clouds at sunset.

Devils Lake, North Dakota, United States

Place Morny, Deauville, in Normandy, France. Sunny town square in with a large fountain spraying water, surrounded by ornate old buildings.

Place Morny, Deauville, Normandy, France

What followed took rather longer. With automatic processing down, NATS cut the number of aircraft allowed into UK airspace to keep the skies safe. More than 2,000 flights were cancelled and the independent review commissioned by the Civil Aviation Authority later put the number of passengers affected at over 700,000, with around 300,000 caught by cancellations. The cost to airlines and airports ran past £100 million. [1] [2]

The NATS investigation makes a point that is easy to miss. The system did the right thing. Confronted with a word that meant two things and no way to tell which, it refused to guess and shut itself down rather than pass a possibly wrong route to a controller. [1] That was a safety decision, built in on purpose.

Now imagine the same ambiguity reaching a system designed to be helpful. One that has read everything, is rewarded for answering, and has no way of knowing that the firm it works for means something specific by a word that means something else everywhere else. It would not stop. It would pick a DVL and tell you, fluently and politely, where the aircraft was going to leave the country.

That is the confident wrong answer, and the only defence against it is a firm that knows, precisely and in writing, what it means.

Where the first four weeks of ‘Beyond the Hype’ have been heading

This series has argued that the data is mostly reachable, that joined-up data you cannot trust is dangerous, that the regulator now wants proof from the data rather than the file, and that the barrier to reaching modern capability has fallen while most organisations have stayed put. Underneath all four sits a pair of preconditions for AI adoption in wealth management that I said at the start would always be presented together: trusted, accessible data, and organisational context.

Week two was about the first. This is the second, and it is the one almost nobody budgets for.

Organisational context is the firm's own meaning. What your products are and how they differ. What your advice process is, in practice rather than in the procedures manual. What a word means in your firm, where it differs from what the same word means in the firm down the road. Which rules bind, which are preferences, and what happens at the edges. All of it exists today. The question is where.

A story from inside a provider

Picture a pensions and investments provider that has just put a new assistant in front of its adviser servicing team. It is good. It drafts responses, pulls policy details, and answers adviser queries in seconds that used to take a callback.

An adviser asks about a client's tax-free cash entitlement on a pension that started in 2004. The assistant answers at once: 25% of the fund, the standard figure, correct for almost every pension in the book. It is wrong for this one. The client has scheme-specific protection that entitles her to more, under rules that pre-date 2006, documented in a product guide last revised in 2011, and known for certain by three people in the business, one of whom retired in the spring. The protection is flagged in a free-text field on the legacy administration system that nobody told the assistant to read, in wording the assistant would not have recognised if it had.

The adviser takes the answer at face value because it is confident, specific and quick. The client is advised on the wrong figure. Nobody finds out until the benefit is crystallised and the money is short.

Nothing in that story is a technology failure. The model worked exactly as designed. What failed was that the provider's own knowledge, the rule that made this customer different, lived in a document, a field and three heads, and not in any form the system could use. And notice that the data precondition failed at the same time: the flag was there, but in a place and a form that made it useless. Context without trusted data is irrelevant, and this is what that sentence means in practice.

Three places the rule lives today

Every firm already has its rules. The question is the form they are in, and each form fails in a characteristic way.

	What it looks like	How it fails
In people	"Ask Janet, she's been here since the merger."	Walks out the door at retirement; applied inconsistently, invisible to any system.
In documents	Product guides, procedures manuals, the compliance handbook, the 2011 PDF.	Out of date without any noticing; written for a reader, not a machine; contradicts other documents.
In code	Validation rules in the back office, workflow conditions, spreadsheet logic.	Correct but opaque; nobody can list them; changed by whoever last touched the system.
In a shared model	The firm’s terms, products, rules and relationships defined once, in a form people and systems both read.	Takes effort to build and someone to won; then every person and every system works from the same meaning.

The first three are where almost every firm I meet keeps its knowledge. The fourth is what the technical world calls an ontology or a knowledge graph, and I have kept those words out of the first six hundred words of this article on purpose, because the idea is older and plainer than the vocabulary. It is the firm's dictionary and rulebook, written down properly, once.

What the regulator's survey says firms do not know

The most recent joint survey of AI in UK financial services by the Bank of England and the FCA found that while 84% of firms had a named person accountable for their AI, only 34% reported a complete understanding of the AI they used and 46% reported a partial one. Four of the top five current risks firms named related to data, with data quality among them. [3] A new edition of that survey was trailed by the FCA last week and should be published imminently; I will update the figures when it lands. [4]

UK financial services AI infographic: 84% have a named person accountable, and 34% fully understand the AI they use.

Read those numbers alongside the provider story. A firm that understands its AI only partially, running it over data it ranks among its own top risks, with its rules held in people, documents and code it cannot fully enumerate, is a firm that has built the conditions for the confident wrong answer and put its name to it.

The readiness data from Alirity points the same way. Strategy scores 2.42 out of 4 across respondents, with internal alignment among the weakest sub-areas, and 49% of organisations lack strategic alignment to deliver AI. [5] A firm that is not aligned on what it is trying to do is rarely aligned on what its words mean.

What I'm seeing

Opinion follows; from the conversations I have with firms and providers rather than from anything I can footnote.

The first thing is that almost no firm believes it has this problem until it tries to automate something. The rules feel known, because the people who know them are in the building. The moment a system has to apply them without a person in the loop, the firm discovers how much was tacit, how much was contradictory, and how much was simply Janet.

The second is that the exercise of writing the rules down is itself the most valuable part, and it is a human exercise before it is a technical one. When a firm sits its product, advice, operations and compliance people in a room and asks them to agree what a term means and which rule wins when two conflict, it finds disagreements that have been quietly costing it money for years. The model you build at the end is useful. The arguments you have on the way are where the value is.

The third is that this is exactly where deploying new technology into old ways of working does its damage. A firm that drops an assistant onto an unwritten rulebook has not automated its process. It has automated its ambiguity, at scale, with a confident voice. The week four article described a good tool landing in an unchanged operating model and producing an expensive version of the old one. This is the mechanism.

And the last is the one that gives me most hope. The barrier to building a shared model of your business has come down with everything else. Ten years ago, it was a research project. Today a mid-sized firm can start with its twenty most important terms and its fifty most important rules, owned by someone in the business rather than in IT, and grow from there. The hard part is not the tooling. It is deciding to do it and deciding who owns the result.

Questions people are asking

What is an ontology, in business terms?

An agreed definition of the things your business deals with, what they are called, how they relate to each other and which rules apply to them, held in a form both people and systems can read. For a wealth firm that means clients, households, products, wrappers, providers, advisers, services, fees, reviews and the relationships between them, plus the rules that govern each. It is a dictionary and a rulebook combined, maintained once rather than rediscovered every time a new system or a new colleague arrives.

What is a knowledge graph, and why does it matter for AI?

A knowledge graph is the ontology populated with your actual data: not just "a client has holdings with providers" but this client, these holdings, these providers, with every link traceable. It matters for AI because it is the difference between a model that answers from general knowledge and one that answers from your firm's knowledge, with the protected tax-free cash flag attached to the client it belongs to. It is also what lets you show why an answer was given, which the FCA's expectations on explainability and accountability increasingly require. [3]

What are AI guard rails?

Limits and rules applied to what an AI system can do, say and act on, drawn from your organisational and regulatory context. Some are hard stops: never state a tax-free cash figure without checking for protection; never suggest a consolidation under targeted support. Some are routing: escalate to a human when the confidence is low or the customer is flagged as vulnerable. Guard rails are only as good as the context they are built from. A guard rail that does not know protection exists cannot protect anyone.

How do you encode business rules for automation?

Start by finding them, which is harder than it sounds, because most live in people and documents. Write each one down in plain language with an owner, a source and an example. Resolve the conflicts, of which there will be more than you expect. Then and only then put them into a form a system can apply, and keep the plain-language version as the master so that a human can always check what the machine was told. The order matters. Firms that start with the technology end up encoding whatever the system vendor assumed.

Isn't this just documentation?

Documentation describes the rules for a reader. Context, in the sense used here, defines them in a form that is checked and applied, by people and systems alike, so that the document and the behaviour cannot drift apart without someone noticing. The 2011 product guide in the story above was documentation. Nobody read it, and the system could not.

The client's side

The client in the story never saw an assistant, a model or a free-text field. She saw a provider she had been with for twenty years give her adviser a figure, confidently and quickly, that turned out to be wrong when it mattered most. The speed made it worse. A slow, hedged answer invites a second look. A fast, specific one does not.

Clients forgive firms that say "let me check". They do not forgive firms that were sure and wrong. And in retirement decisions, which are mostly irreversible, there is rarely a second chance to be right.

Who's doing it well

The clearest public example is the regulator's own attempt to solve this problem for itself. Since 2018 the FCA and the Bank of England have run Digital Regulatory Reporting, a programme to see whether regulation could be written in a form machines could execute, so that firms' systems could produce regulatory returns directly instead of people interpreting rules and keying data. Two pilots ran in 2018 and 2019, and a third phase is under way. The foundational requirement the programme identified was not better technology. It was data standardisation: getting everyone to agree what the terms in a rule mean before anyone tries to automate the rule. [6] If the regulator with the rulebook found that the hard part was the meaning, firms applying those rules should expect nothing different.

The pensions dashboards programme, four days from its connection deadline as this is published, is the same lesson at industry scale. Before any provider could return a member's data, the whole sector had to agree a common data standard for what a pension record contains and a matching convention for what counts as the same person. The standard came first and the connections followed. [7]

What AI adoption in wealth management means for you

If you run an advice firm

Your advice process, service tiers, charging rules and product preferences are your context, and most of them live in the heads of your advisers and your compliance manager. Before any tool touches a client file, write down the twenty terms and the fifty rules that matter most, with a name against each. That exercise will surface disagreements you did not know you had, and it costs nothing but an afternoon.

If you are a product provider

Your legacy book is a museum of rules that apply to specific cohorts of customers and are documented in forms nothing can read. Every one of those is a confident wrong answer waiting for an assistant. Start with the exceptions, because the standard cases look after themselves, and link each exception to the trusted customer record you were building in week two, or the flag will sit in the wrong place as it did in the story.

If you are a consolidator

You have acquired six vocabularies. The same word, "review" or "ongoing service" or "vulnerable", means six slightly different things across the group, and every integration programme I have seen underestimates this. Agreeing one meaning per term, before the platform migration rather than after, is the cheapest piece of integration work you will ever do and the most often skipped.

In plain English: ontologies and knowledge graphs

An ontology is an agreed description of the things that matter in your business: what they are called, how they relate and what rules apply to them. A knowledge graph is that description filled in with your real data, so that each client, product and rule is connected to the others and every connection can be followed. Together they are a firm's dictionary and rulebook in a form that people and systems both use, which is what stops the same word meaning two things in two places, and what lets a system explain why it gave the answer it did. They are not new ideas. What is new is that building one is now within reach of a firm without a research department.

One thing to do this week

Pick one word your firm uses every day. "Review" will do, or "household", or "vulnerable". Ask five people in different roles to define it without conferring. Count the versions.

Then find out which one your systems use.

If you would like a structured view of where your firm stands across data, customer, people, strategy, governance and technology, the AI Readiness Assessment takes about ten minutes and gives you a personalised report on your readiness and next steps: Home | AAIR

The air traffic system stopped because it would not guess. Most of the systems being sold into this market will not have that instinct. Give them yours.