2024 Q2 Report: Off to a Busy Start
Company-related · Reports
Introduction
While this report arrives a little late, this really goes to show how much is happening at the moment.
In the past quarter, we have been exceptionally busy with building our product, and we are currently half-way there to launching our working prototype. On the side, we have been preparing a lot of longer-form content to describe the inner workings of our architecture, and we are excited to share it over the upcoming weeks. We have already been talking to many people, and we have received valuable feedback on our product design. Overall, it appears as though we are onto something. Our number one priority is launching our prototype, and getting it in your hands as quickly as possible. From here on out, everything that we do is geared towards reaching that simple (yet ambitious) target.
In terms of product, we will actively implement the GAMR architecture, together with other building blocks (trading system, exchange system, and messaging engine) that are immediately relevant to our proof of concept[1]. Besides, we put particular emphasis on good UI and UX design, which poses a completely separate challenge in itself (talking about potentially streaming terabytes of market data to your browser). Thinking one step ahead, we will already prepare the META-GAMR architecture and other building blocks that we need to complete our flagship product, that is, our multi-market simulation platform. This involves a great deal of work, given that all of those different building blocks are later to become stand-alone products.
In terms of company, we will complete our foundational structure, installing the “Obliquid Financial Intellectual Property” (OFIP) subsidiary to hold (and secure) most of our software. This step has taken longer than expected, and we are planning a stand-alone article to discuss the many challenges involved therein. Moreover, we will continue to talk to as many people as possible. In doing so, we have the intention of both growing our network (through potential customers and investors) and growing our team (through technical team members). To make that possible, we will also look into different funding opportunities for early-stage start-ups.
Ultimately, we understand that people will not truly care about our solution until we deliver a proof of concept. In that sense, our prototype acts as a “catalyst” for engagement, if you will. Consequently, our content strategy is primarily meant to get people excited about our launch. Once we show that it can be done, however, we also want to show how it’s done. In doing so, we concentrate on the underlying models and our user interface, given that those carry the innovation that sets us apart. Consequently, our content strategy is also meant to provide an extensive project documentation that people can always come back to.
Q2 2024 Review
So … what have we been up to?
Our current product landscape
These are the different components that we have been actively working on over the past few weeks.
OFIP <DIVISION>
Trading System <PRODUCT>
Backend-Server-Instance <MODULE>
Interface <CATEGORY>
In-bound Interface <COMPONENT> * · · · · · · · · · · · ·
Out-bound Interface <COMPONENT> * · · · · · · · · · · · ·
Exchange System <PRODUCT>
Backend-Server-Instance <MODULE>
Interface <CATEGORY>
In-bound Interface <COMPONENT> * · · · · · · · · · · · ·
Out-bound Interface <COMPONENT> * · · · · · · · · · · · ·
State <CATEGORY>
Market State <COMPONENT> * · · · · · · · · · · · · · · ·
Matching Engine <COMPONENT> * · · · · · · · · · · · · · ·
Messaging Engine <PRODUCT> * · · · · · · · · · · · · · · · · · · · ·
OFRS <DIVISION>
GAMR Architecture <PRODUCT>
Backend-Server-Instance <MODULE>
Environment <CATEGORY>
Simulation Environment <COMPONENT> * · · · · · · · · · ·
Training Environment <COMPONENT> * · · · · · · · · · · ·
Component <CATEGORY>
Market Memory <COMPONENT> * · · · · · · · · · · · · · · ·
Market Context <COMPONENT> * · · · · · · · · · · · · · ·
Market Update <COMPONENT> * · · · · · · · · · · · · · · ·
Market State <COMPONENT> * · · · · · · · · · · · · · · ·
Model <CATEGORY>
Context Generator <COMPONENT> * · · · · · · · · · · · · ·
Update Generator <COMPONENT> * · · · · · · · · · · · · ·
Storage <CATEGORY>
Episode Storage <COMPONENT> * · · · · · · · · · · · · · ·
Backend-Client-Instance <MODULE>
Application <CATEGORY>
Application <COMPONENT> * · · · · · · · · · · · · · · · ·
Storage <CATEGORY>
Session Storage <COMPONENT> * · · · · · · · · · · · · · ·Product-related objectives
Looking back on our product-related objectives, we have mostly been able to remain on schedule. Only in regard to potential partnerships, we have made the conscious decision to keep a low profile until we are able to back up our claims (with a working prototype).
OFRS :: GAMR <PRODUCT>
🟢 24Q2-P01 (100%). Complete prototyping stage 1, evaluating a large number of different design options in moderately sized training jobs to identify the optimal architecture.
🟢 24Q2-P05 (100%). Conceptualize a “foundation model” strategy to make GAMR universally compatible, able to capture and simulate any asset at any point in time.
🟡 24Q2-P02 (40%). Complete MVP (minimum viable product), developing a simple user interface that is able to showcase the potential of GAMR, and that will later turn into our simulation platform.
- Currently under way, scheduled for late Q3 2024.
🔴 24Q2-P03 (0%). Partner with trading firms that are willing to test our solution, allowing us to evaluate how well it is able to estimate a trading strategy’s performance compared to its historical track record (which is an important part of our evaluation approach).
- We’re waiting for the prototype, scheduled for late Q3 2024.
🔴 24Q2-P04 (0%). Partner with educational institutions that are willing to test our solution, allowing us to gather larger amounts of user feedback for our beta-testing initiative.
- We’re waiting for the prototype, scheduled for late Q3 2024.
OFIP :: Trading System <PRODUCT>
🟢 24Q2-P06 (100%). Implement the in-bound gateway that receives and handles large amounts of market data, including adapters for different market data protocols (starting with Xetra T7 EOBI and Nasdaq TotalView ITCH).
🟢 24Q2-P07 (100%). Implement the market state that serves as a single source of truth for the entire system, including the set of data structures that are used for the internal representation of the limit order book (LOB).
🟢 24Q2-P08 (100%). Implement data quality checks and fail-over mechanisms that handle data errors and system failures.
🟢 24Q2-P09 (100%). Implement the order position tracking overlay.
OFIP :: Messaging Engine <PRODUCT>
🟡 24Q2-P10 (30%). Implement the set of high-performance data structures that drive the messaging engine, including in particular ring buffers (log buffers) and memory-mapped files.
- This is not too pressing at the moment, scheduled for Q1 2025.
🔴 24Q2-P11 (0%). Run benchmarks on our data structures, and optimize performance with regard to both latency and throughput.
- We’re waiting for the data structures, scheduled for Q1 2025.
Company-related objectives
Looking back on our company-related objectives, we are pretty much done setting up the Obliquid Financial holding structure. In regard to regulatory concerns, we have made the conscious decision to wait for the working prototype before we approach the responsible body.
🟢 24Q2-C02 (100%). Set up our licensing structure around our company structure.
🟢 24Q2-C05 (100%). Seek partnerships that would provide access to compute infrastructure and level 3 market data (for our prototyping stage 2).
🟢 24Q2-C06 (100%). Prepare international trademark registration through World Intellectual Property Organization (WIPO).
🟡 24Q2-C01 (90%). Incorporate “Obliquid Financial Intellectual Property” (OFIP) subsidiary to complete our company structure foundation, built to safeguard our intellectual property.
- We’re almost there, all the paperwork is ready.
🟡 24Q2-C04 (30%). Establish meaningful partnerships with pilot customers that are willing to provide us with insight about their business needs (important for our product-market-fit).
- We’re waiting for the prototype, but we have already received valuable feedback from industry veterans.
🔴 24Q2-C03 (0%). Talk to the regulatory body (BaFin) about our planned product line-up.
- We’re waiting for the prototype, scheduled for late Q3 2024.
Q3 2024 Outlook
And what will happen next?
Our extended product line-up
These are the products that we will start developing in Q3 2024. Over time, we will outline each of these products in an extensive multi-part series of medium articles.
META-GAMR architecture. The “META-GAMR” orchestration layer is used to synchronize multiple GAMR instances in a multi-market simulation environment. This way, it is possible to simulate spill-over effects across multiple markets. Once a local interaction happens, the orchestration layer takes the global planning perspective and relays the information to all other nodes. On this basis, the local GAMR instances are able to simply operate within the bounds that they are provided by the global META-GAMR orchestration layer. The multi-market simulation environment is an important step towards our fully-fledged simulation platform.
Exchange System. The “Exchange System” is the counterpart to our trading system, built for institutional-grade, ultra-low-latency (ULL) exchange operations in the cloud. Its modular architecture is organized only at the infrastructure level, and it is therefore much more straight-forward to build than the trading system. Today, it is used to maintain the simulation state that is driven by the GAMR (and META-GAMR) architecture, thereby forming the basis for our simulation platform. In the long term, we want to turn it into a white-labeling solution for cloud-based trading venues (at the moment, that would mostly pertain to CeFi trading venues).
Product-related objectives
We continue to prioritize our GAMR architecture, and we are building trading system and exchange system only insofar as they are needed for our prototype. The messaging engine is currently not too relevant, given that there are more pressing performance bottlenecks that need to be addressed first.
OFRS :: GAMR <PRODUCT>
24Q2-P02*. Complete MVP (minimum viable product), developing a simple user interface that is able to showcase the potential of GAMR and that will later turn into our simulation platform.
24Q2-P03*. Partner with trading firms that are willing to test our solution, allowing us to evaluate how well it is able to estimate a trading strategy’s performance compared to its historical track record (which is an important part of our evaluation approach).
24Q2-P04*. Partner with educational institutions that are willing to test our solution, allowing us to gather larger amounts of user feedback for our beta-testing initiative.
24Q3-P01. Build infrastructure-level components, that is, everything that happens immediately around our model.
24Q3-P02. Build application-level components, that is, everything that makes our model accessible through our user interface.
24Q3-P03. Implement our MLOps workflows to streamline our model (re-)training.
24Q3-P04. Complete prototyping stage 2, training larger-scale models based on the most promising design options identified in prototyping stage 1.
24Q3-P05. Implement our foundation model strategy to make GAMR universally compatible, able to capture and simulate any asset at any point in time.
24Q3-P06. Prepare our cloud deployment on AWS infrastructure.
OFRS :: META-GAMR <PRODUCT>
24Q3-P07. Design the “META-GAMR” architecture that allows to orchestrate multiple GAMR instances in a multi-market simulation environment (prerequisite for our simulation platform)[2].
24Q3-P08. Obtain level 3 market data from many different trading venues, serving as large-scale training data for our production model.
OFIP :: Trading System <PRODUCT>
24Q2-P08*. Implement data quality checks and fail-over mechanisms that handle data errors and system failures.
24Q3-P09. Implement the out-bound interface, sending orders and receiving confirmations.
24Q3-P10. Implement a first version of our strategy container that is used for running the actual trading strategy.
24Q3-P11. Implement a first version of our data handler, processing data to inform the strategy container (e.g., signal generation).
24Q3-P12. Implement a first version of our order handler, processing orders to inform the strategy container (e.g., risk checks).
OFIP :: Exchange System <PRODUCT>
24Q3-P13. Implement the in-bound interface, receiving orders and sending confirmations.
24Q3-P14. Implement the out-bound interface, publishing different market data feeds.
24Q3-P15. Implement the matching engine that operates on the level 3 market state.
OFIP :: Messaging Engine <PRODUCT>
24Q2-P10*. Implement the set of high-performance data structures that drive the messaging engine, including in particular ring buffers (log buffers) and memory-mapped files.
24Q2-P11*. Run benchmarks and optimize performance with regard to both latency and throughput.
Company-related objectives
In the upcoming weeks, we will need to do a lot of talking. On the one hand, we need to ensure that people know (and care) about our launch. On the other hand, we need to ensure that we learn more about our potential customers’ business needs. Aside from building a great product, this remains our foremost priority.
24Q2-C01*. Incorporate “Obliquid Financial Intellectual Property” (OFIP) subsidiary to complete our company structure foundation, built to safeguard our intellectual property.
24Q2-C03*. Talk to regulators (BaFin) about our planned product line-up.
24Q2-C04*. Establish meaningful partnerships with pilot customers that are willing to provide us with insight about their business needs (important for our product-market-fit).
24Q3-C01. Talk to investors.
24Q3-C02. Talk to industry veterans and try to win them over as our advisors.
24Q3-C03. Search for technical team members, including a dev lead (software), a dev lead (hardware), and a cloud/infra lead.
24Q3-C04. Grow our reach to several hundreds of subscribers, implementing our content strategy across LinkedIn, Medium, and Reddit.
24Q3-C05. Apply to different funding programs for early-stage start-ups.
24Q3-C06. Upgrade our company website.
Conclusion
With our first milestone in sight, these are our closing thoughts.
We are on schedule to deliver our first working prototype in late Q3 2024, and we want to get it in your hands as soon as possible. Since there is a lot of complexity involved, we believe that our prototype will best be able to speak for itself. In other words, spending five minutes playing around with our prototype is much more intuitive than spending several hours reading our longer-form content. Since the “GAMR” architecture brings together our entire product landscape, it is the ideal showcase for the many other things that we are building in the background. Compared to those other things, it is much more fun to look at (and arguably much easier to bring to market). Ultimately, we want to leverage our first working prototype to drive overall engagement.
Moving forward, we want to turn our initial prototype into our flagship product (simulation platform). To complete the multi-market simulation platform, the next step then will be to build our “META-GAMR” orchestration layer.
Should you want to learn more about our solution, let’s get in touch.
