GAMR Architecture (Intro): Generative Adversarial Market Response

Research-related · Closed-source

Setting the stage …

Let’s say that you are backtesting your high-frequency trading (HFT) strategy.

The best that you can do is to take your historical market data and play the unreliable game of “what would have been”. However, you cannot be sure how the market would have responded, so you essentially estimate a performance “discount” to adjust and lower your expectations. Moreover, you cannot go beyond what has already happened, so you are always limited to previously observed market scenarios. This is far from ideal. Instead, consider the following solution.

There is a generative deep learning based foundation model that you can essentially “play against”, as though you were playing against the market (hence the name “GAM[E]R”). This generative model is designed not only to provide an appropriate market response, but also to produce any market conditions that you prescribe. You start with some historical episode (your historical market data), and then you go from there. Based on a simple and intuitive user interface, you come up with some more or less detailed market scenario, and the generative model shows you precisely what that would look like. More robustness, more resiliency, and more realism.

This is what we are able to provide.

Fig. 1: The simulation platform includes both market model (upper half) and system model (lower half). The GAMR architecture poses the fundamental building block behind our market model.

1 ­‎‎ Introduction

1.1 ­‎‎ ­‎‎Our solution in a nutshell

The “GAMR” architecture is an integral part of our simulation platform, monitoring and updating the limit order book (LOB) in response to both previous market activity and real-time control input.

📈 On the one hand, our solution provides an appropriate “market response”, running in a feedback loop to generate each market update as a function of previous market events (including prior model output). This way, we are able to model market impact deep within the LOB, which allows for much more insight than a traditional price impact model (see chap. 2).

🎯 On the other hand, our solution is always tracking some target, running alongside a historical episode that serves as our reference market. This way, we are able to ensure that the market simulation does not simply drift away from desirable market conditions (see chap. 3).

🕹️ On the same basis, our solution further provides a means of “market control”, allowing the user to manipulate the target and thereby take indirect control over the market simulation (while maintaining the same degree of realism). This way, we are able not only to imitate a historical market, but also to design any black swan event from scratch[1] (see chap. 4).

Simply put, it serves as a drop-in replacement for a market environment, and it generates an instantly responsive order stream that can not only be interacted with, but that can also be controlled.

1.2 ­‎‎ Where it belongs

The “simulation platform” is our multi-market simulation environment for the optimization and evaluation of trading strategies and trading systems. It operates on two separate levels, infrastructure and application.

In terms of infrastructure level, it uses the same ultra-low-latency (ULL) building blocks as our trading platform, integrated with our simulation models. The “market model” is used to simulate the market environment, driving and orchestrating the market state within and across multiple markets. It takes a “back door” perspective on the exchange system, implicitly modeling the latency as part of the aggregated order flow. The “system model” is used to simulate the system environment, allowing to infer the projected round-trip time (RTT) under any given situation (e.g., during the fail-over of a critical service). It takes a “front door” perspective on the exchange system, explicitly modeling the latency for each individual packet.

Simply put, these models help to answer two important questions — “does my trading strategy make profitable decisions?” (market model) and “is my trading system fast enough to capitalize on those decisions?” (system model).

In terms of application level, it provides additional features (e.g., experiment tracking and parameter sweeps), built around an optimization engine that turns large amounts of event data into actionable insights.

Simply put, these features help to answer two important questions — “which combinations of strategy parameters and market conditions produce which outcomes?” and “what do I need to change in order to improve performance?”.

1.3 ­‎‎ ­‎‎What it does

Within our simulation platform, the GAMR architecture forms the basis for our market model. It communicates in two opposite directions, the individual market and the orchestration layer.

Each individual market is driven by a local GAMR instance, serving as a proxy for the aggregated order flow that comes from other market participants. In other words, GAMR is used to simulate market dynamics in top-down fashion.

At the same time, each local GAMR instance is synchronized with a global “META-GAMR” instance, serving as an orchestration layer that keeps everything aligned. In other words, META-GAMR is used to simulate spill-over effects across multiple markets. The orchestration layer is “passive”, in the sense that it is used only to relay information about local interactions. It does not interact itself. Once a local interaction happens, the orchestration layer takes the planning perspective and informs all the other nodes about where they need to go. The local GAMR instances simply operate within the bounds that they are given.

1.4 ­‎‎ ­‎‎How it works

In principle, the GAMR architecture resembles a simple feedback loop. However, we extend the feedback loop with what we refer to as “target tracking”, allowing us to have the simulation episode run alongside a target episode (a specified reference market). Our approach is to reduce current market conditions to a lower-dimensional representation, leading to an information bottleneck through which simulation and target are loosely connected (decoupling approach). This lower-dimensional representation can then also be manipulated.

Conceptually, this approach is somewhat similar to a Variational Autoencoder (VAE), given that we do not manipulate the market state in its entire complexity, but we instead manipulate a latent representation from which the market state is then derived[2]. In our approach, the latent variables are both manipulable and interpretable, allowing for the user to take precise control over the model output. Without target tracking, the market simulation would take a random path and therefore not provide any reasonable means of control. We believe that a better approach is to use a historical episode as a starting point.

So … which problems are we trying to solve?

2 ­‎‎ ­‎‎Background

2.1 ­‎‎ ­‎Trading simulation and its challenges

The simulation of a high-frequency trading (HFT) system requires careful consideration of both market and system behavior. Fundamentally, it attempts to estimate the performance that, in hindsight, some simulated strategy would have likely shown under historical market conditions. Generally speaking, a sophisticated simulation engine will implement a transaction cost model that accounts not only for commissions and fees, but also for liquidity-bound market impact and latency-bound slippage.

On the one hand, “market impact” denotes any change in market state that happens in response to a given market event[3]. Ultimately, this is what our market model is designed to address. On the other hand, “slippage” denotes the difference between the expected and realized outcome of a given market event, resulting from any change in market state over the time of transmission[4]. Ultimately, this is what our system model is designed to address.

The notion of market impact in particular poses a challenge, given that a simulated order that never actually happened would influence the historical order stream indefinitely, in terms of both immediate (deterministic) and self-induced (stochastic) impact. Moreover, additive impact introduces additional complexity, which is why trading simulation tends to be rather unreliable.

Traditionally, this challenge has been dealt with in one particular way.

2.2 ­‎‎ ­‎The traditional approach

The “market replay” approach iterates over historical updates (read from a historical dataset) to reconstruct a historical state. Here, a passive order cannot add liquidity to the historical state, and an aggressive order cannot remove liquidity from the historical state (the impact persists only until the next historical update). In other words, the simulated liquidity is simply overlaid on top of the historical state … if it were treated as part of the historical state, this would cause the historical state to increasingly drift away from the original market conditions. Consequently, the market replay is not able to provide an appropriate market response.

When orders are small, this is not a problem (also referred to as the “small order assumption”). When orders are large, however, one would need a traditional price impact model to adjust the performance estimate[5].

Here, “price impact” denotes an adverse change in market price that arises in response to a given trade. Compared to market impact, this definition is much more tangible. In theory, it describes the difference in price trajectory with and without a given trade (of which only one or the other can ever be observed). In practice, it is therefore approximated by the difference in market price before and after a given trade (measured after a fixed time horizon). A traditional price impact model is used to estimate this difference as a function of market conditions and trade parameters, and the resulting value is then subtracted from the performance estimate. It is conceptually treated in isolation, and it does not account for additive impact (multiple trades) and market drift (underlying trends). It is rather simplistic.

Generally speaking, a market replay can be considered more an initial indication than a reliable validation (even when accounting for price impact).

• Problem 1. We rely on a single value (price impact) to describe complex market dynamics, and it does therefore not provide much insight.
• Problem 2. We are inherently limited to market scenarios that have already happened.

It is for these reasons that a market replay can never replace live testing, where there is actual money on the line.

Consequently, it is necessary that we detach from historical market data.

2.3 ­‎‎ ­‎‎The modern approach

The “market generator” approach produces simulation updates to reconstruct a simulation state, entirely detached from historical market data. Here, a passive order can add liquidity to the simulation state, and an aggressive order can remove liquidity from the simulation state (the impact persists indefinitely). This is possible because the underlying model is able to readjust with every simulation step, thereby keeping the simulation state within a reasonable range. Consequently, the market generator is generally able to provide an appropriate market response, and it is not reliant on any other model[6].

This is the path that we are opting for. However, we still believe that the market replay should remain a part of the solution, given that a user will typically need a starting point (a specified reference market).

2.4 ­‎‎ ­‎‎Our approach

Our “target tracking” approach is a hybrid solution between market generator and market replay, having the simulation episode run alongside a historical episode. Our primary model (“update generator”) is running in a feedback loop to drive the simulation state, one step at a time. Simultaneously, the same model is also tracking a target (either a historical episode or some variation thereof). By manipulating the target, the simulation episode can effectively be “hijacked” to go somewhere else. Our secondary model (“context generator”) is running in the background to ensure that the bigger picture always continues to make sense. This way, we are able to have the best of both worlds (and more).

With our hybrid approach, we are able to model complex market dynamics, but also have them remain accessible.

• Solution 1. We are able to provide an appropriate market response (market impact), allowing for a strategy to participate directly within and as part of the simulation state.
• Solution 2. We are able to provide a means of market control, allowing for a user to manipulate the simulation episode for better robustness and resiliency.

Overall, we make trading simulation much more meaningful, and our objective is to estimate live trading performance with minimal error (on average).

How does our solution work, exactly?

Fig. 2: The GAMR architecture includes both target domain (upper half), simulation domain (lower half), and the differential context in between.

3 ­‎‎ ­‎‎Architecture

3.1 ­‎‎ ­‎‎Structural underpinnings

Our approach is based on the premise that a simulation episode is always imitating some historical episode (target tracking). Consequently, the architecture is organized into target domain and simulation domain.

• Target domain. The target domain iterates over a historical episode, representing the target that is to be tracked by the simulation.
• Simulation domain. The simulation domain generates a simulation episode, informed by both itself (any previous steps) and the target domain (current step).

The simulation episode is generated one step at a time (feedback loop), with each step passing through a sequence of stages. Accordingly, the architecture is organized into memory stage, context stage, update stage, and state stage.

• Memory stage. The memory stage maintains a history of both current and previous market conditions (“market memory”), thereby ensuring internal consistency over time.
• Context stage. The context stage uses a lower-dimensional representation (“market context”) to summarize the market memory in terms of different proxy variables, which we also refer to as “context dimensions” (e.g., liquidity measures, volatility measures, and depth measures)[7].
• Update stage. The update stage uses a market or limit order submission or cancellation (“market update”) to manipulate the market state, informed by both market memory and market context.
• State stage. The state stage maintains the current state of the LOB (“market state”), reconstructed from the previous market state and the current market update.

Together, domain and stage dimension form a grid of eight primary components (target memory tm, target context tc, …, and simulation state ss). These components are connected through two separate feedback loops, and through the target tracking that happens between them (see design principles 1–2).

Fig. 3.1: Design principle 1 (“feedback loop”).

Design principle 1. The simulation episode is generated one step at a time (“feedback loop”).

The underlying feedback loop is driven by our primary model (“update generator”) that estimates each market update as a function of market memory (and other conditional input). Since the market state can always be reconstructed from a sequence of market updates, we model the market update (incremental change) instead of the market state. It is important to understand that a market episode is always based on event time (as opposed to clock time), meaning that the market updates are irregularly spaced in time. With each market update, the update generator therefore decides not only “what” it is that should happen (order parameters), but also “when” it should happen (time delta). Without any external reference, however, the market simulation would simply take a random path. It would essentially produce some market conditions, but almost certainly not those that we are looking for.

In the simulation domain (market generator), we are dealing with a “pre-match” update, that is, a market or limit order submission or cancellation that triggers a matching step[8]. This type of update is handled by the same matching engine that drives our exchange system.

Fig. 3.2: Design principle 2 (“target tracking”).

Design principle 2. The target domain leads, and the simulation domain follows (“target tracking”).

To keep the market simulation on track, we first need to define what the “track” should actually look like. In our opinion, the most intuitive way is to use a historical episode as a starting point. This is because the user will typically look for certain market characteristics, and because it would be too overwhelming to start designing from scratch. Consequently, we extend the simulation domain (market generator) with the target domain (market replay), running both loops in parallel. To have the simulation track the target, we share information about its relative position to the target. This happens through market context, acting as conditional input to our primary model (“update generator”). Ultimately, the idea is that this information allows the update generator to track the target state, despite not actually being able to observe the target state. Since we share only limited information about the target state, the update generator is forced to come up with creative output, and to solve what is essentially a path finding problem.

Get Jonas De Paolis’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In the target domain (market replay), we are dealing with a “post-match” update, that is, any addition, modification, or deletion that results from a given matching step[9]. This type of update is handled by the replay engine. It is important to understand that there exists a one-to-many relationship between pre-match update and post-match update. One order can lead to multiple changes in the LOB.

3.2 ­‎‎ ­‎‎Round-trip

Going forward, we describe a single round-trip (a single simulation step) that passes through each of the above-mentioned components. In doing so, we are able to give a quick tour of our architecture.

• Target update. In the beginning, we load a single target update tu_curr from a historical dataset that serves as our reference episode.
• Target state. Next, we use tu_curr to reconstruct the target state ts_curr = f(ts_prev, tu_curr) in our replay engine (RE).
• Target memory. On this basis, we start the next simulation step and add the previous ts_curr (now ts_prev) to the target memory tm_curr.
• Target context. Last, we use tm_curr to compute the target context tc_curr = f(tm_curr), a vector that includes a value for each context dimension.

So far, so good. But here comes the tricky part … how do we go from target domain to simulation domain? Since we want to generate highly similar (yet not completely identical) market conditions, we need to solve the target tracking problem.

3.3 ­‎‎ ­‎‎Decoupling approach

To implement the target tracking, we introduce a decoupling approach that allows us to share just the right amount of information. The decoupling approach is based on what we refer to as “differential context” (and “differential state”), serving three separate functions (see design principles 3–5).

Fig. 3.3: Design principle 3 (“domain decoupling”).

Design principle 3. The simulation domain is bound to the target domain, albeit loosely (“domain decoupling”).

We share information through both differential context and differential state. The differential context allows to compare simulation and target ex ante, serving as a relative measure that informs our primary model about where the simulation currently stands relative to the target and, consequentially, where it needs to go in order to “look” more like the target. Simply put, this means that a difference in midpoint (as an example for a context dimension) will signal to the simulation that it needs to move in a direction that minimizes the differential context along that particular context dimension. This way, the simulation “magnetically sticks” to the target, so to speak. The differential state allows to compare simulation and target ex post, serving as a basis to evaluate whether the simulation has been able to produce the desired outcome (which is relevant only during model training).

Fig. 3.4: Design principle 4 (“abstraction decoupling”).

Design principle 4. The market context provides the high-level planning, and the market state does the low-level implementation (“abstraction decoupling”).

The architecture operates on two levels of abstraction, market context and market state. On the one hand, the market context provides a vaguely defined roadmap for the entire market episode, taking a high-level planning perspective from start to finish (across many thousands of steps). This way, it leaves room for a large number of possible outcomes. On the other hand, the market state takes a low-level implementation perspective, following the roadmap so as to non-deterministically provide a plausible market update (one step at a time). This way, it presents only one out of infinitely many possible outcomes. With a given target context, we are therefore able to achieve a wide variety of very similar simulation episodes.

Fig. 3.5: Design principle 5 (“temporal decoupling”).

Design principle 5. The target domain and the simulation domain are connected through a continuous-time look-up function (“temporal decoupling”).

We always pre-compute the target context for the entire target episode. Ultimately, we need to achieve temporal decoupling between simulation domain and target domain, meaning that a simulation update must be possible irrespective of there being a target update at the exact same point in time. It is for this reason that we smooth the event-time target context into a continuous-time look-up function tc(t), evaluable at any point in time. If we simply expressed the target context as a step function, we would run into the problem that we may be only 1 nanosecond away from the next “step”, but we simply wouldn’t know. By smoothing the target context, we make sure that the underlying trend is identifiable at any point in time. In some sense, the differential context thereby allows for a glimpse into the “future”, the future being the target context at that point in time.

3.4 ­‎‎ ­‎‎Round-trip continued

With the target tracking figured out, we are able to translate between target domain and simulation domain. The differential context serves as a single point of contact through which all information is shared. It is the one component that makes target tracking possible.

• Differential context. Here, we compute the differential context dc = tc(t) - sc between target context tc(t) and simulation context sc, providing insight about where the simulation domain stands relative to the target domain (along each context dimension).
• Simulation update. Given this conditional input, our primary model (“update generator”) is able to produce the next simulation update su_curr = f(dc, sm_curr).
• Simulation state. Next, we use su_curr to reconstruct the simulation state ss_curr = f(ss_prev, su_curr) in our matching engine (ME).
• Simulation memory. On this basis, we start the next iteration and add the previous ss_curr (now ss_prev) to the simulation memory sm_curr.
• Simulation context. Last, we use sm_curr to compute the simulation context sc_curr = f(sm_curr).

This concludes a single round-trip. Since the first half of the round-trip is pre-computed (and exists implicitly in the target context), we directly continue with the second half of the round-trip.

3.5 ­‎‎ ­‎‎Interaction mechanisms

So far, we have described the inner workings of our architecture. From this point onward, we describe the ways in which the architecture can be interacted with (see design principles 6–7).

Fig. 3.6: Design principle 6 (“market control”).

Design principle 6. It is possible for a user to take (indirect) control over the market simulation (“market control”).

We allow for a user to take control over the market simulation. More precisely, the user is able to manipulate individual context dimensions in the target context look-up function, thereby (indirectly) changing the course of the simulation episode. Since this leads to inconsistency both within and across context dimensions, however, the bigger picture may no longer make sense. To address this issue, our secondary model (“context generator”) completely regenerates the entire target context, every time that a change is made (macro perspective). To constrain the output, we ignore any values that have been actively manipulated by the user, and also any values that lie in the simulation “past” (i.e., that have already been processed by the update generator). Working around these constraints, the context generator essentially solves an imputation problem, meaning that only a subset of values is sought. It is important to note that any context manipulation is performed in a background process, outside of the primary control flow. This way, the main process does not get interrupted by user input. Ultimately, we are able to provide a means of market control. The user manipulation is optional, however, and it is also possible to leave the target context in its original form.

Fig. 3.7: Design principle 7 (“market response”).

Design principle 7. It is possible for a strategy to participate in the market simulation (“market response”).

We allow for a strategy to participate in the market simulation. More precisely, a strategy update (market or limit order submission or cancellation) is able to add and remove liquidity to and from the simulation state. Since this leads to an actual impact on the simulation state, however, the simulation episode needs to be held within a reasonable range. To address this issue, our primary model (“update generator”) produces an ongoing stream of market updates that result in the desired market dynamics (micro perspective). We treat both strategy update and simulation update exactly the same. Although a strategy update is technically produced outside of the market simulation, it is still reflected in the simulation memory. When a strategy update has higher time priority than the currently scheduled simulation update, the current step is suspended, and the next step is triggered. This way, the update generator is always able to process the latest information. Ultimately, we are able to provide an appropriate market response. The strategy participation is optional, however, and it is also possible to leave the simulation episode running on its own.

The simulation state is maintained through an incremental stream of simulation updates. Consequently, the way that we model the market response is indirectly through the simulation update, rather than directly through the simulation state. This requires what we refer to as “update generation” (obligatory). The “update generator” takes the implementation perspective for the current step, producing the simulation update as a function of simulation memory (feedback loop) and differential context (target tracking). Consuming the simulation memory alone, the update generator would be able to immediately respond to a market event, given that it operates in auto-regressive fashion. However, it would not be able to plan further than one step ahead, let alone as far as the entire market episode. With the differential context on top, the update generator is able to simply follow directions, and to rely on the target context for the planning perspective.

🔗️ ­‎‎ ­‎‎To learn more, see our follow-up article “GAMR Architecture (Part 1): Update Generation and Market Response”.

The target context outlines the entire target episode, that is, the bounds within which the update generator is able to operate. While the target context can be used in its original form, it can also be manipulated to achieve a means of market control. This requires what we refer to as “context generation” (optional). The “context generator” takes the planning perspective over the entire target episode, regenerating the entire target context from start to finish. This is relevant only once the user has actively manipulated the target context, thereby causing inconsistency both within and across context dimensions. In such cases, the context generator jumps in and brushes over the target context, so that everything continues to make sense. In other words, it paints a bigger picture that always looks plausible, despite any changes made by the user.

🔗️ ­‎‎ ­‎‎­‎‎To learn more, see our follow-up article “GAMR Architecture (Part 2): Context Generation and Market Control” .

It is important to note that the update generator may still deviate from the prescribed target context, but only if the implementation would otherwise not make sense. Remember that the update generator needs to reconcile both differential context and simulation memory, which may potentially lead to conflicting objectives.

And what can we do with it?

Fig. 4: The user interface includes both market editor (left side) and market handler (right side).

4 ­‎‎ ­‎‎Usability

4.1 ­‎‎ ­‎‎User interface

The “market editor” is our user interface for context manipulation, required to take control over the simulation episode. Without the market editor, market control would practically not be feasible, given that the target context involves a large amount of information (millions of underlying values) that could never be entered by hand. Consequently, we provide tooling that makes things easier. The market editor is built around a simple line graph that describes the target context over the entire target episode. Since the market context involves multiple context dimensions, we provide both an editing tool (a primary read-and-write context slot) and a managing tool (a list of secondary read-only context slots). When a secondary context slot is clicked, the corresponding context dimension is loaded into the primary context slot. Over there, the user is able to make changes.

In the beginning, the user always starts with some historical episode (target episode) that they want to explore. On that basis, the user can add one or multiple “segments”, that is, portions of the original target context that they want to change. Within a segment, the user can add one or multiple “waypoints”, that is, points through which the target context is required to pass. Each waypoint spans all context dimensions, but the user may also specify values for only a subset of context dimensions. In that case, the context generator will simply impute any missing values.

Each value can be manually set by using drag & drop on the line graph (quick option), or by using the input form in our detail view (precise option). The user can add as many waypoints as they need to point the context generator in the intended direction. After the changes for a given segment have been confirmed, the user can click on a button to regenerate the target context. Should the results not fully satisfy the user’s requirements, this step can always be repeated. The user can add multiple segments, the idea being that those are the portions that they actively want to control. The target context outside of those segments is automatically readjusted so that the overall target episode continues to make sense.

The more waypoints the user sets, the less variability in outcome there can be. If constrained too much (with waypoints that do not make sense), the context generator will nonetheless adhere to those rules and, in consequence thereof, simply produce bad output. To mitigate this issue, we use a “discriminator” model that evaluates the degree of realism in a given segment. On this basis, we include a confidence score that helps the user identify potential problems.

The “market handler” is our user interface for path management, required to navigate the different paths that the market simulation has taken. It essentially helps to navigate the tree structure that underlies a session, resulting from jumping back and starting over from different checkpoints onward. Throughout a session, this tree structure can grow to a considerable size. In this tree structure, every path that leads from a leaf node to the root node can be considered a separate market episode.

🔗️ ­‎‎ ­‎‎To learn more, see our follow-up article “GAMR Architecture (Part 3): UI and UX Design”.

4.2 ­‎‎ ­‎‎Derived applications

Based on the user interface, we are able to support a wide range of use cases.

• Trading simulation (performance testing). Simulate strategy performance based on some historical episode, generating a virtually unlimited number of variations that share highly similar market characteristics (increased robustness).
• Trading simulation (stress testing). Simulate strategy performance under extreme market conditions, using the market editor to design any edge case that would need to be considered (increased resiliency). Use the built-in discriminator to evaluate the realism in a market episode that has been manipulated (confidence score).
• Market simulation. Use a stand-alone market environment for research purposes, studying different market phenomena (e.g., spill-over effects).
• Data augmentation. The market simulation can also be used simply to perform data augmentation (i.e., to generate more training data).

Moreover, we are able to support the following usage patterns.

• Interactive strategy development. Use both market editor and market handler to make changes while the simulation is running, providing instant feedback about the interplay between different combinations of strategy parameters and market conditions. Here, the optimization engine works in ad-hoc fashion, providing insights that help the user navigate the parameter space (and thereby augment their intuition).
• Traditional simulation. Run thousands of simulations in parallel, allowing for large-scale evaluation. Here, the optimization engine works in systematic fashion, including grid searches, random searches, and more.
• Real-time scenario analysis. Use the market simulation in an “online” setting, performing real-time scenario analysis during live trading.

5 ­‎‎ ­‎‎Conclusion

5.1 ­‎‎ ­‎‎What we are building

With the GAMR architecture, we take a different approach to trading simulation, and we are thereby no longer bound to historical market data. Without compromising on realism, we are able to provide an instantly responsive order stream that can not only be interacted with (strategy participation), but that can also be controlled (user manipulation).

We use a generative model (“update generator”) to provide an appropriate market response, modeling market impact deep within the limit order book (LOB). This way, you are able to actually observe the market impact of your strategy, rather than relying on a traditional price impact model.

We provide a means of market control, and we use a generative model (“context generator”) to ensure that the resulting market episode continues to make sense. This way, you are able to take a historical episode (as a starting point) and turn it into something completely different, up to and beyond a black swan event (more resilience). On top of that, you are able to produce a virtually unlimited number of variations for a given market episode (more robustness). Conveniently, all this can happen at run time, introducing the use-case of interactive strategy development.

The market control is based on a user interface (“market editor”), offering the tooling that is required to design a market scenario. This way, you are able to effectively (and efficiently) “draw” a market scenario with nanosecond precision, and with no constraints on creative freedom.

Our solution estimates trading performance with minimal error, and it simultaneously allows for significantly more flexibility. Simply put, our solution makes trading simulation (strategy backtesting) overall much more meaningful.

5.2 ­‎‎ ­‎‎What else you can expect

In terms of additional features, these are other things that may interest you as well.

• Ultra-low latency (ULL). We use the same underlying ULL building blocks for both simulation platform and trading platform, allowing you to better understand your production environment.
• Exchange protocols. We use the actual exchange protocols, so that you do not need to make any changes to your production code.
• Low-level event logs. We provide access to low-level event logs, allowing you to navigate the entire complexity that underlies our event-driven system.
• Level 3 market state. We use a level 3 market state for internal representation, modeling the LOB in full resolution (and in full depth).
• Foundation models. We use foundation models as they allow for better coverage, better capacity, as well as streamlined retraining workflows.
• Cloud deployment. We deploy the simulation platform on AWS, and we provide access through AWS Cluster Placement Groups.

5.3 ­‎‎ ­‎‎Where we are going

In the bigger picture, we want to provide solutions not only for market participants alone, but also for market operators and market regulators. Ultimately, we want to shift from trading simulation more toward market simulation, that is, from treating the market as a black box (and not caring too much about the internals) to building increasingly sophisticated models to explain market dynamics. This in particular is why we take the foundation model approach.

5.4 ­‎‎ ­‎‎How you can help

If this solution sounds like something that you’d be interested in using, we would very much appreciate your feedback. In particular, we are looking to partner with a handful of smaller trading firms that would like to be involved in the process. On the one hand, we want to learn more about your business needs, and about the implications that those may have for our product design. We are happy about any feature request coming from your side. On the other hand, we will soon need volunteers for our beta-testing initiative, making sure that our model performs as intended. Take it for a test drive, tell us what you think.

If this problem sounds like something that you’d be interested in working on yourself, we would love to hear from you as well. We are always in search of engineering talent.

Thank you for your interest, we will keep you updated on our development progress.

This article belongs to a multi-part series. The other articles can be found below (once they are published). ­‎‎

GAMR Architecture (Intro): Generative Adversarial Market Response
GAMR Architecture (Part 1): Update Generation and Market Response
GAMR Architecture (Part 2): Context Generation and Market Control
GAMR Architecture (Part 3): UI and UX Design­‎‎

Obliquid Financial

https://linkedin.com/company/obliquid-financial/

https://www.obliquid-financial.com/
­‎‎

Footnotes

[1] We always require a historical market episode as a starting point, given that the user will typically look for certain market characteristics. Moreover, it would be too overwhelming to design everything from scratch.

[2] More precisely, our approach is to use a latent representation to generate the market update, and to use the market update to reconstruct the market state.

[3] In a narrow sense, “market impact” denotes the difference in market price that arises in response to a given trade.

[4] In a narrow sense, “slippage” denotes the difference between the expected and realized price of a given trade, resulting from any market movement between the time of order submission and execution.

[5] There exist other variants of the market replay that do support market impact and try to compensate the resulting market drift by injecting additional orders, slowly driving back the simulation state towards the historical state. However, these variants require strong assumptions in terms of both the decay rate of the temporary impact and the absence of any permanent impact.

[6] So far, a break-through has yet to happen. This is an active area of research, and we are looking to move the needle.

[7] This being a generative setting, the market context is used only to inform the market update, and it has nothing to do with feature engineering or boosting model performance. Instead, the market context is what ultimately drives the entire market simulation.

[8] The pre-match update is equivalent to the in-bound order stream (to the exchange system) that generally cannot be observed by market participants.

[9] The post-match update is equivalent to the out-bound “level 3” market data feed (from the exchange system) that is consumed by market participants.