For a long time, financial technology supported a fairly clear division of labour. Business people understood the financial problem, analysts translated it into requirements, architects designed the system, and developers implemented it.

That model was never as clean as the organisation chart suggested, but it worked well enough. A developer could spend years building trading systems, data pipelines, APIs or reporting platforms without deeply understanding every financial concept behind them. If the requirement was clear and the interface was defined, the job was largely to turn that specification into reliable technology.

AI is changing that.

Not because financial institutions will suddenly stop needing technologists. And not because every developer needs to become a trader, accountant, lawyer or risk manager.

The change is more fundamental: AI is reducing the amount of hands-on implementation required for many technology jobs, while increasing the importance of understanding the problem, making decisions and judging whether the solution is actually right.

Those are much harder things to do without understanding the domain.

When implementation was expensive, implementation itself created value

A large part of traditional technology work exists because building software has historically been expensive.

Someone has to write the SQL. Someone has to create the API. Someone has to map one schema into another, build the validation rules, write the tests, create the deployment configuration and document the result.

Even when the problem is well understood, turning a specification into working software takes time and specialised skills.

That has allowed technologists to specialise around implementation. If somebody else has already determined what the system should do, there is still substantial value in knowing how to make it do it.

AI is beginning to reduce that cost.

Coding assistants can already generate large amounts of routine application code. They can write queries, tests, mappings and documentation. They can explain unfamiliar code, propose refactorings, generate API clients and help developers work with frameworks they have never used before.

This does not make software engineering trivial. Complex systems remain complex, and generated code still needs judgement, testing and governance.

But the direction is difficult to ignore.

When implementation becomes cheaper, simply being able to implement a well-defined requirement becomes less scarce.

The value starts moving somewhere else.

The job moves upstream

Imagine that somebody gives you this requirement:

“Show me our exposure to securities issued by ABC.”

In the old model, much of the technologist’s work might begin after the requirement had already been clarified. A business analyst may have identified the correct data sources, agreed what exposure means, determined which issuer relationship to use and specified how the result should be calculated.

The technologist then builds it.

With AI, more of that implementation can increasingly be generated or assisted. The harder part is what happens before the code.

What does ABC refer to? A legal entity, a corporate group, a trading name or an identifier?

What counts as a security for this question?

Does issued by mean the direct legal issuer, or does the business really want exposure aggregated to the parent group?

Does exposure mean current holdings, market value, credit exposure, settlement exposure or something derived from several of them?

Which date matters, and which source is authoritative for this purpose?

None of these questions is primarily about Java, Python, SQL, cloud architecture or APIs.

They are questions about the financial problem.

If AI can generate much of the implementation after these decisions have been made, then the human technologist increasingly creates value by helping make the decisions correctly.

That requires domain knowledge.

But even more importantly, it requires semantic judgement: the ability to recognise which distinctions matter before they disappear into code.

Correct technology can implement the wrong meaning perfectly

This is one of the most important consequences of AI-assisted development.

Suppose a schema contains a field called issuer_id. A developer asks an AI coding assistant to build a function that retrieves securities issued by a particular company.

The implementation is straightforward. The AI generates the query, creates the tests and exposes the result through an API. Everything works.

Unfortunately, imagine that issuer_id in this particular system does not contain the direct legal issuer. Years ago, the field was repurposed to contain the ultimate parent because that was more useful for a reporting process.

The code can be technically perfect.

The tests can all pass.

The result can still answer the wrong business question.

This problem is not unique to AI, of course. Financial systems have always been capable of implementing the wrong requirement very efficiently.

What AI changes is the speed.

If generating the implementation becomes much easier, then understanding whether we are implementing the right meaning becomes proportionally more important.

AI does not just make correct implementation cheaper.

It can make semantic mistakes cheaper to implement too.

The scarce skill therefore moves from:

“Can you build this?”

towards:

“Do we actually understand what should be built?”

The technology-only career becomes more fragile

This has an uncomfortable career implication.

There will continue to be highly technical roles where deep technical expertise is the job. Financial institutions will still need specialists in areas such as distributed systems, cybersecurity, high-performance computing, database engineering, quantitative infrastructure, low-latency systems and AI engineering.

Some technology problems are difficult precisely because the technology itself is difficult.

But those roles represent only part of financial technology.

A much larger group of technologists works on enterprise applications, data platforms, integration, analytics, reporting and increasingly AI-enabled business systems. In these areas, AI can accelerate more of the mechanical implementation work.

That does not mean those jobs disappear. It does mean that technology alone becomes a less complete professional proposition.

More of the remaining human work involves analysing ambiguous requirements, understanding context, choosing between alternatives, identifying risks and deciding whether an AI-generated solution makes business sense.

Those activities require more than technical competence.

They require judgement.

And judgement in financial technology requires enough understanding of finance to know where meaning matters.

AI is not eliminating the financial technologist. It is reducing the space in which a financial technologist can remain only a technologist.

You do not need to become a financial expert in everything

This argument can easily be misunderstood.

A technology architect working in capital markets does not need to become an expert in every derivative, accounting treatment, regulatory regime and operational process.

That would be neither realistic nor particularly efficient.

The point is not that technologists need to know everything about finance.

They need to know enough to recognise when an apparently simple requirement hides an important distinction.

Consider a few examples.

Is an identifier the thing itself, or merely a code assigned to it?

When an organisation is described as an issuer, are we talking about the organisation itself or its participation in a particular issuance relationship?

Is a security the same thing as one of its exchange listings?

Is a price simply a timeless attribute of a security, or an observation made under a particular source, time and context?

If a contract is amended, what changed? If it is novated, what stayed the same — and what did not?

These may sound like modelling questions, but they have direct consequences for software.

If we confuse identity with identifiers, we may create duplicates when identifiers change.

If we turn contextual roles into permanent types, we may struggle to represent the same legal entity participating differently in different transactions.

If we collapse a security and its listings, we may lose the venue-specific meaning of identifiers or prices.

If we treat a market price as a timeless attribute, we immediately struggle when two sources report different values.

The technologist does not need to become the final business authority on these questions.

But they do need to recognise that the questions exist.

That is a very different standard from simply knowing the schema.

Domain experts and technologists need a better conversation

As implementation becomes easier, the conversation between business and technology becomes more important.

Suppose a domain expert says:

“The issuer is ABC Holdings.”

A conventional requirements process might record that statement and move on.

A semantics-aware technologist should become curious.

Do we mean that ABC Holdings legally issued the bond?

Or is ABC Holdings the parent of the issuing entity?

Is it the entity used for risk aggregation?

Does this answer apply to every business process?

Could the relevant relationship change through time?

Which source tells us this, and which source should we trust for this particular purpose if two systems disagree?

Those questions are not technical obstruction. They are how an apparently simple statement becomes precise enough to implement safely.

The domain expert contributes knowledge of the financial world and the business context. The technologist helps expose the distinctions that need to survive into the system.

Neither side can do the whole job alone.

Business experts cannot simply say, “Technology will work out what we mean.” Technologists cannot say, “The field is called issuer_id, so the meaning is obvious.”

AI makes that partnership even more important because ambiguity can now be converted into working software extremely quickly.

AI makes domain knowledge easier to acquire

There is a useful irony here.

AI is making domain knowledge more important for technologists, but it is also making domain knowledge much easier to learn.

A developer who encounters novation for the first time no longer has to begin with a 300-page product manual. They can ask an AI to explain the concept, compare it with amendment and termination, walk through an example, identify the parties and obligations involved, and answer follow-up questions until the basic structure becomes clear.

The same applies to securities, corporate actions, collateral, settlement, positions and many other financial concepts.

Used well, AI can dramatically shorten the distance between “I have never worked with this concept” and “I understand enough to ask sensible questions.”

But there is an important boundary.

AI can explain how novation generally works. From that general knowledge alone, however, it cannot reliably determine how a particular institution treats contract identity through a particular kind of novation, which lifecycle distinctions matter to the business process, which source should govern a decision, or which semantic distinctions the systems need to preserve.

Those answers have to be established from the relevant financial semantics, business context, policies, systems and evidence.

AI can help discover them. It can compare documentation, inspect models and code, propose interpretations, identify inconsistencies and generate useful questions.

But a plausible interpretation should not silently become the organisation’s semantic commitment.

That still needs to be challenged and agreed.

The valuable technologist moves up the semantic stack

This suggests a broader change in where human value sits in financial technology.

At the implementation end of the stack, AI is becoming increasingly capable. It can help generate code, queries, mappings, tests, interfaces and documentation.

Move upward, however, and the questions become harder.

What problem are we actually solving?

What does this financial concept mean?

Are these two representations genuinely equivalent?

Which distinction matters for this process?

What changed, and what stayed the same?

Are two sources actually disagreeing, or are they describing different contexts?

What must remain true even if the implementation changes?

These are questions about meaning, context and judgement.

The better AI becomes at producing implementations, the more important it becomes to understand what those implementations are supposed to represent.

In that sense, the financial technologist of the AI era is moving up the semantic stack.

Business problem
        ↑
Financial meaning
        ↑
Semantic model
        ↑
Data / rules / APIs / applications
        ↑
Implementation

AI can increasingly help us move through every level of this stack.

But generating something at a higher level is not the same as knowing that it is right.

That is why semantic judgement matters.

This is where ontology becomes practical

Ontology modelling fits naturally into this changing role.

That does not mean every financial technologist needs to learn formal logic or become an expert in RDF and OWL. The useful starting point is much simpler.

When somebody says two records represent the same thing, ask what the thing is.

When a business term appears in several systems, ask whether the systems actually mean the same concept.

When an organisation is called an issuer, ask what makes that issuer relationship or participation true in this context.

When a value changes, ask whether the financial thing changed, its state changed, or somebody simply made a new observation about it.

When two sources disagree, ask whether they are making conflicting claims about the same thing under the same context, or whether the apparent disagreement disappears once time, source or meaning is made explicit.

These are ontology questions in ordinary language.

They are also increasingly the questions that determine whether an AI-enabled system solves the right financial problem.

This is why ontology should not be thought of merely as another specialist technology. For the financial technologist, it can become a practical discipline for understanding the domain well enough to preserve its meaning when that meaning becomes data, software or AI behaviour.

The technology still matters.

Engineering still matters.

Domain expertise still matters.

What is changing is where they meet.

As AI makes implementation easier, the valuable financial technologist increasingly needs to understand not only how to build the system, but also what financial world the system is supposed to represent.

That is the move up the semantic stack.

And it is why financial ontology modelling is becoming a much more practical skill than its name might suggest.

• *Financial Ontology Modelling