The initial problem: intervene before consequence
Online fraud presents a timing problem. Detecting an event after the core system has completed it may be useful for investigation, but it is too late to prevent the transaction. Effective control must operate in the request path, understand context and act before the application commits the outcome.
The early FMT software was designed for that task. It observed interactions with internet-banking and related systems, applied intelligence and changed the course of the request when risk required it.
The product solved a fraud problem. Its architecture revealed a broader capability.
The unexpected property
Once deployed, the software could access and alter the data moving into and out of a legacy system without changing the underlying application. To the consumer, the visible behaviour of the system had changed. Internally, the system remained the same.
That separation was significant. It meant the cost and delay of a complete application release were not inherent in every requirement. Some requirements could be implemented at the interaction boundary, where they were easier to isolate, prove and reverse.
The discovery was not that one fraud control could be reused. It was that the data path could become an independent place for programming enterprise behaviour.
Separating the architecture from the use case
The next research task was to remove assumptions that belonged only to fraud. What was the generic unit of interaction? How could different protocols be understood? Which capabilities were deterministic, which could use probabilistic intelligence and how could both be governed? How should security, performance and resilience be retained?
This led to a distinction between the foundational runtime and the solutions composed upon it. Authentication, compliance, analytics, security, transformation and customer experience were not separate products at the architectural level. They were different outcomes created by programming the same position in the data path.
Enterprise environments became the test
A foundational architecture must survive more than a demonstration. It must operate under real transaction volumes, complex protocols, strict availability requirements and governance processes. Deployments across financial services and other demanding environments tested whether the approach could remain stable, performant and supportable over time.
Those environments also exposed the importance of non-functional requirements. A capability that is functionally correct but cannot fail safely, scale, produce evidence or be repaired in operation is not an enterprise solution.
The research therefore expanded from runtime programming into deployment, probes, telemetry, management and repair.
From programmable runtime to composable platform
As the number of outcomes grew, repeated bespoke development would have recreated the problem the architecture was intended to solve. The technology evolved to separate reusable capabilities, protocol understanding and deployment controls.
The Editor became the place where functional requirements are programmed and composed. The Console became the place where non-functional requirements are selected, deployed and retained through operation. Programmable Data Agents became the distributed runtimes that execute the solution in the data path.
Together, these form the Composable Agentic Platform: a way to turn learning from one engagement into governed capability available to the next.
Why the name Data Mediation
Mediation describes an active role between parties. It does not merely transport data. It understands enough context to reconcile differences, apply policy and shape an interaction while allowing each side to remain autonomous.
Data Mediation therefore names both the discipline and the architectural position. It encompasses access, management and control of data in motion between systems, users, applications, models and networks.
The original fraud use case remains a valid application. It is now one point in a much larger space that includes AI governance, cyber control, interoperability, migration assurance and any other outcome that can be programmed around the data journey.