Recent Posts

Sunday, December 17, 2017

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: 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


  1. I'm looking at something similar, but keeping it simple and likely having the structure in Javascript to start with to avoid the issues of managing the server. There are enough playables in Javascript to get simple models going.

    Certainly you'd want to get away from python at the backend unless there are some significant library advantages. I've never been a big python fan. I sort of like Elixir to get the parallelism, but worry it might be overkill to start with.

    I've also wondered if you could run this on a distributed ledger - cryptocurrency style. That then deals with how you pay for it. People buy gas on Ethereum or something.

    We should put our heads together in the New Year and see if we can come up with an initial target.

    Like yourself, the problem is having enough quality time to get the dev environment operating and the release system in place.

    1. It's a client-server architecture, but it can run on a single machine using the loopback port. (People with strict firewalls might have some difficulties.) Some "clients" could be folded into the "server" process as well. But based on my experience, you want the ability to run separate clients. You can seamlessly run debugging clients that watch the simulation state while the thing is running.

      I like Python, and it has a lot of tools to do something like this. But people could implement either servers or clients in whatever language they wish; it would all communicate versus the loopback port.

  2. You mentioned the difficulty with price determination in models. That triggered refection on a Steve Keen observation that I recently read. A past school of economic thought (Steve said) observed that agriculture manages toward a production surplus.

    A goal of surplus is only logical--we want no-one to starve. But how is the surplus handled?

    Agriculture does not depend upon steady, matched prices. Instead, some crops make money, some lose money, but on the average, farmers must make money to stay in business year-after-year. Actual surpluses are managed, if possible, into low value but accumulating efforts such as beef production. Quality-for-price varies widely, especially in wildly ranging seasons.

    Finding a single price is just the opposite from what actual markets experience.

  3. Hah, I should have guess that you Brian are into games as well!

    I have been building something similar in my spare time for some time yet I think my aim is elsewhere. For me the idea is straightforward but I have been surprised how many microstructure (not necessarily linked to microeconomics as we know it) problems I have encountered, which are really fundamental (micro fundamental?). One example is the price stickiness that varies across different types of trades. The other is information which the agents act upon. Anyway, treating economy as a game is an enlightening way to get one's head around on various phenomena.

    I think such a game/framework would make a great educational tool, which would be extremely helpful for students of economics and might protect them from the sirens of the mainstream.

    1. I read that one too. Thanks. I'm not sure whether a game like this can succeed outside the class rooms and the circles of hobbyist. For a class room I think that the game can and probably should be realistic.

      Below I will write down some of my ideas. These might be totally incompatible with yours. So this are just some ideas and quite vague ones. I hope you/someone find them interesting and maybe even useful.

      I would keep it simple, just a basic competition and no significant scale advantages etc. But I would allow and embrace the balance sheet abuse as it is a way to create more dynamic into the game. And that's realistic too. And I would have more than one good economy to keep the most aggression at the bay, driving others out by low prices will make other industries more profitable. One of the keys are how easy it is to create a monopoly and keep it that way. One avenue, even if not being simple anymore, is to take supply chains onboard. That is one way to limit the dominance as every firm agent/player is then dependent on the layer(s) above. Chains are known to create chaotic systems out of simple action rules, which might be good. Anyway offering different roles at least different industries might be way to go.

      Also striking the balance between cooperation and competition will be important. I would seek the balance using simple pieces which yet allow many different strategies. Easier said that done. One way is to allow a great deal of leverage opportunities. That's a tool for catching up too, one or two player out of a big pool of small leveraged players are almost surely guaranteed to catch up one that is trying to ensure the current wealth and thus is not very leveraged. Credit money is then given and banking might be better to leave to AI players for example to avoid unwanted collusion opportunities etc. Also I think a lot of coding trouble will be avoided. Not sure, human bankers playing to win would certainly create a lot of havoc. Leverage relates to the next idea.

      One interesting way, once all the other bases are covered, is to restrict information among the players. That way the game is theory-wise incomplete information game (like poker). This also makes randomness endogenous, catching-up is easier and not even that necessary for gameability as you often cannot be sure whether you are losing or ahead. And I think information plays an important role in the actual economy too. We really don't know the actual balance sheets and contracts between other agents. E.g. think about goldsmith-bankers. I loved this story (fact?):

    2. I have been doing some coding. Right now, I am pretty much at the basic level: how do I structure the communications system? I looked at my existing code, and realised I needed to encapsulate things differently. The core systems have to be developed in a way that it is easy to debug the system. It would be easy to get excited about the flashy economic systems, and end up with an architecture where it is impossible to develop AI algorithms.

      I am probably re-inventing the wheel. But at the same time, I need to have complete control over the communications protocol; if we have hundreds of agents, a general purpose gaming client-server architecture would be swamped. I am not coding for efficiency now, but I will be able to refactor later.

      Since it’s open source, I don’t think it’s going to be a money-maker. At best, *I* could try making money writing a manual explaining how to use the framework. Somebody could use it as a prototyping tool, but everything would probably have to be redeveloped from the group up for efficiency.



