Comments On Structuring An Agent-Based Economic/Financial Simulator

One of the problems with standard stock-flow consistent (SFC) models is that price determination is somewhat difficult to model. (In fact, the sfc_models framework has not even attempted to do so at the time of writing.) One possible way of dealing with this issue would be to add price determination in flex-price markets (such as financial and futures markets) set by agents. Such models could create quite believable behavioural patterns. The problem is that it is difficult to fit such models to real world data. However, the fact that the behaviour is believable makes such simulations a useful teaching tool -- or economic engine in a video game.

The discussion here almost solely reflects my thinking on the topic. One of my hobbies is writing video games, and I built similar simulators almost a couple of decades ago. From what I have seen of the academic agent-based modelling literature, it is roughly compatible with my thinking, but my goals were somewhat different.

High Level Model Description

It should be noted that I am describing what I see as the minimal, interesting simulator of this type. It would be possible to extend this structure in any number of directions.

The problem with creating believable behaviour among agents in a model is that it is difficult to model the varying types of relationships between firms. It is extremely unlikely that two competing soft drink manufacturers would collaborate on an investment project, yet they would both happily lobby politicians for a tax break together. A human can understand such behaviour, but it is hard for an algorithm to emulate it.

The way to eliminate such considerations from a model is to have inter-firm transactions done on arms-length basis through a market mechanism. I will assume that these transactions are done on an exchange.

When we switch to transactions with households, we switch to more aggregated behaviour, and pricing is done on an administered basis. Retail prices are set as a markup over wholesale (exchange) prices, and move relatively infrequently. Most workers have a fixed wage rate that is periodically re-negotiated. Since the wage bill appears to be largely fixed in the short term, manufacturers have a basis to price outputs using a markup over costs.

Exchanges: Hyper-Fast

The first chunk of the model are the exchanges, and firms that use those exchanges. All wholesale transactions for goods are done on the basis of limit orders through an exchange; we can have multiple exchanges to allow trade over a distance.

For now, we ignore the existence of a real economy and just assume that we have a group of firms with an initial allotment of commodities, and they have algorithms they use for portfolio allocation.

What we should expect to happen is that there will be an initial burst of trading, until trading finally ceases. If we fire off trades every microsecond (of simulation time), the burst may last a millisecond or so. (It may take a lot longer to run the simulation.)

Why does trading have to cease? Take the simplest case, one where a single firm acts as a market maker, and every other firm is a price taker. Unless the market maker is run by idiots, there is a non-zero bid-offer spread at all times. This means that any firms that trade are taking a loss versus mid-market pricing, and they would eventually go bankrupt if they keep trading. (There may be some strange corner cases I am omitting, but it is hard to beat this principle.)

If we have multiple market makers, trading could theoretically oscillate forever -- the market makers would lose money on some classes of transactions, while gaining on others. However, to keep the cycle going, it would require the firm management not pulling the plug on losing strategies -- which is implausible.

In summary, the markets will move to an "equilibrium" position where everyone is staring at each other across bid-offer spreads.

The Real World: Slow

The real economy does not operate at a microsecond frequency. Since it is somewhat rare for employees to change jobs within the same working day, the shortest effective frequency is daily.

Let us look at the typical flow of cash for households. They get paid every couple of weeks, and then buy goods at retail stores at various points during the day.

This will impact the previous model by having periodic cash outflows for wages, and retailers accumulating small sales increments during the day. Once the retailers have sold enough goods retail, they will need to replenish their inventories by buying in the wholesale market. This kicks the market balance in one direction or another -- possible causing a flurry of trading activity as portfolios are adjusted.

(We could also have aggregated statistics available at a lower frequency -- monthly, say. Any agents that use economic data in their pricing algorithms would adjust their portfolios in response to this news.)

If the real economy simulation staggers aggregate flows to and from the "real economy" appropriately, the market simulation would start to resemble real-world trading patterns.

Generating the aggregate flows to and from the various sectors of the real economy is straightforward: we can adapt existing behavioural functions from SFC models.The only real trick is to switch from simultaneous end-of-period settlement to coming up with rules to break up aggregate flows to various discrete points in time within larger accounting periods.

Credit -- A Casualty of the Strategy

Simulating credit relationships in such a framework is difficult, since everything is arm's length. (The real economy part of the model can feature aggregated lending, such as banks having portfolios of household mortgages.)

The simplest way to incorporate leverage is to have a margin system on the exchange. We can assume that the government backs the exchange (levying a transaction tax), and so we do not have to worry about the whole thing collapsing financially. However, it would be possible to have a debt deflation -- firm's collateral value is marked down, and so their borrowing capacity is cut, forcing commodity sales to rebuild liquidity. Such forced selling drops prices, and so we get a self-reinforcing bear market.

How Feasible Is Building Such a Model?

Although such a model appears extremely complex, it would actually be straightforward to build. The strategy is to use a client-server model, following the pattern of how real-time strategy games are designed. (Note that you would not need a dedicated machine running as a server; the client and server can run on the same machine. If packaged correctly, most users would not realise it is client-server, unless their firewalls complain about the intra-process communication.)

The server implements the exchange rules, and runs the real economy simulation. We then have client programs that simulate the firms. The clients communicate with the server, getting market prices, and generating trades, as well as doing things like fixed investments and hiring workers.

You just need to ensure that you have firms that are active in every income loop in the model. For example, if you have firms that produce energy, but there are no energy consumers, those firms will just fail. The background simulation also has to ensure that flows do not drop out of the system; for example, wages need to be largely consumed, and household savings eventually returning as well.

The beauty of a client-server architecture is that it is well suited for open source collaboration. People can write their client programs in whatever computer language they like (as long as the language supports socket communication).

Application to the Real World

I have my doubts that we can build such a model and use it to generate forecasts. However, it will generate plausible economic simulations with pretty much all of the data you could possibly want. We could calculate simulation aggregates, and use them as "experiments" for validating statistical techniques.

This would be useful for naysayers like myself. We could run tests to see whether it is possible to invalidate statistical techniques. For example, it may be possible to generate simulations that appear to have an r* that has about the same predictive value as r* in the real world -- even though interest rates do not appear in any agent's decision-making process.

It's a Video Game!

The above structure would work as the economic engine of a video game. In fact, I built a similar game back around the year 2000. The key difference from the above description is that I was not then familiar with SFC models, and so the real economy part of the engine could only be described as terrible. In fact, I got interested in macro modelling largely as a result of wanting to improve that engine. (I worked in fixed income, but my modelling work was largely standard market economist analysis.)

This experience partly explains my aversion to mainstream economics. If you try to apply the insights of mainstream macro to this task, you rapidly find that it is completely useless. Where's my representative household? No where to be found. Even though SFC models are hardly perfect, you can stick a version of them into the engine.

For most programmers, working with a client-server architecture is difficult. However, I am not concerned by this, as I already worked through most of the issues. I have a client-server architecture that I put up on GitHub that could easily be re-purposed for this task:  https://github.com/brianr747/Simple4Xpygame. The game in the package itself is not hugely interesting, but the client-server code could be used in a space trading game. (I used this code in another card game I wrote, but I cannot release because it is based on someone else's intellectual property.) My main goal in the 4X project was getting a clean debugging framework set up, which is the biggest problem you face in development.

I will probably stick some design notes into that GitHub package, to explain further my thinking about the architecture. What mat appear to be arbitrary decisions are actually the result of a lot of consideration.

If I ever have spare time, I could probably convert it to a bare bones economic simulation fairly quickly. If anyone were interesting in pursuing such a project, they could fork the project, and I could help out. (One of the questions to be looked into is what software license to use. I used Apache since it had the shortest licensing files.)

One obvious question some readers might have is: could someone make money selling such a game? They could try, but based on my experience, it would probably be a lot more fun puttering around with the trading algorithms than playing the game. A pure economic simulator does not have a lot of character; blowing up pixel monsters is a lot more fun. It might be possible to put the player in the role of a central banker, in which case they do not have to worry about the rather bland personality of the firms in the simulation.

Use as a Teaching Tool (?)

The project would straddle two roles: a possible base for research simulations, and as a open source game engine that hobbyists like myself could putter around with. One possible way to kickstart interest would be to have a contest for developing trading and investment algorithms, which is the hardest part of the project to set up; without rules for every activity loop, the simulation breaks down. However, once all aspects of the simulation are covered, it is easy to start extending it in whatever direction one wishes.

I could help seed an initial contest, and work with educators to set up a framework so that students without much programming skills would be able to implement mathematical trading rules into the framework. (For example, I could send the winning student a signed copy of all my books -- the losers get two copies!) 

(c) Brian Romanchuk 2017