By Michail Kolpidis
A machine can perform an action. A payment system can record a transfer. Neither fact, on its own, tells us under what economic conditions that action should have taken place.
That is the next question for machine-native finance.
In my first note on the subject, I drew a distinction between execution and settlement. The distinction matters because a record of value moving is not the same thing as the physical or digital activity that created the value. But there is another boundary inside that separation. Technical ability to act does not, by itself, establish the economic terms of participation.
If machines are to take a larger role in shared infrastructure and services, we need to be able to name that boundary clearly.
One service, several different facts
Consider a shared water pump serving several farms. A control system can start it. A meter can record its use. An invoice can allocate a charge. Each of these is a useful fact, but they answer different questions.
The start command tells us that the machine was asked to operate. The meter tells us something about what happened. The invoice tells us how a cost was later recorded. None of those facts alone tells us whether the service took place under the economic conditions agreed by the people and organisations involved.
Was this use within an agreed allocation? Which party was entitled to request the service? Which obligation arose from the period of use? Those are not merely accounting questions, because the economically relevant activity is occurring at the machine. They are not merely engineering questions, because the answers concern rights, costs, and responsibility.
The pump is an example, not a proposed design. The same question can arise wherever a machine grants access, consumes a shared resource, measures a service, or performs work for more than one party.
The missing question sits between capability and record
We can describe a machine transaction through three public questions:
- What can the machine technically do?
- Under what economic conditions should that action count as permitted participation?
- How should its financial consequence be recorded and settled?
These questions are related, but they should not be compressed into a single payment event.
The first belongs to the world of devices, software, and physical capability. The last belongs to records, claims, transfers, and reconciliation. The middle question concerns the terms under which an action becomes economically meaningful. It is the question most likely to disappear when a project begins with a wallet, an API, or an invoice.
A machine may be technically able to act even when a service should not be provided on the same terms. A payment may be recorded even though the record alone does not explain which real-world event it represents. Better messaging or faster settlement cannot remove the need to define that relationship.
Useful tools do not erase the boundary
APIs can carry instructions and information. Billing systems can price and describe usage. Ledgers can preserve records. Payment networks can transfer value. Programmable transactions can make some financial steps conditional. These capabilities matter, and many future systems will use them.
Yet each tool still needs a clear account of the machine activity to which it relates. An API call is not automatically an economic permission. A usage total is not automatically a complete explanation of the obligation it creates. A settlement record is not automatically proof that the underlying service occurred under the intended conditions.
Some systems already address parts of this problem for a particular device or operator. Machine-native finance asks how to treat the problem as a general category rather than as a collection of local exceptions. That shift begins with language precise enough to keep the action, its conditions, and its later record distinct.
A place for the Financial Runtime conversation
I use the phrase Financial Runtime as a marker for this missing field of inquiry: the relationship between economically relevant machine activity and the conditions under which that activity should take place. It is a way to ask what finance must understand while a service is being performed, not only before it starts or after it ends.
At this stage, the important point is structural. We do not need to publish a technical blueprint to see that a machine economy has more than a payment problem. It has a participation problem. The financial meaning of an action cannot be inferred solely from the machine's ability to perform it or from a later account entry.
That insight changes the order of the questions. Before asking which payment rail a machine should use, ask which event matters economically. Ask whose terms govern that event. Ask what a later record must be able to represent faithfully.
Then the choices about payment, billing, and settlement can be made in relation to the activity they are meant to support.
Start with the conditions
Machines are entering more areas where services are continuous, shared, measured, and automated. The language of finance must become capable of describing participation in those settings without pretending that the device, the service, the obligation, and the payment are all the same thing.
That is the structural claim behind machine-native finance. A machine's action has technical reality. Its use has economic conditions. Its consequences need financial records. A serious architecture has to keep all three in view.
The next step is not to draw every internal connection. It is to ask the right public question: under what conditions should machine participation occur?