Over the last weeks, we have been reaching out to as many potential candidates as we were able to find … which, as it turns out, are really not that many. Since we are targeting doctoral students with a very specific background in high-performance computing (HPC) and hardware acceleration, the number of potential candidates is rather limited. The good news is that we have been able to find some very capable people who have already expressed interest in joining our mission. The bad news is that it cost a lot of time to get there (time that could have otherwise been spent on training and coding). At this point, it feels as though we have to sacrifice some momentum in order to achieve more output down the road.
In terms of product, we have spent many hours turning some of our low-level engineering tasks into stand-alone work packages, serving as a basis to bring in external collaborators. In other words, we have been dealing more with high-level reference implementation and specification than with low-level performance optimization. With the above-mentioned tasks on hold, we have been able to finish both building our Update Generator (primary model) and designing/prototyping our Context Generator (secondary model). There is a lot more to be said about our research progress, but this quarter has really been more about solving our organizational challenges.
In terms of company, we have designed the above-mentioned work packages in a way that would appeal to the right people (“right” as to the roles that we are seeking to fill). At the same time, we have been actively searching for those people all over GitHub and LinkedIn, channeling our inner HR specialists. On the PM side of things, we have planned both our team (and ownership) structure and our business strategy in a way that is going to support our product development as much as possible. Having made these plans, we are ready to accommodate additional team members in the foreseeable future.
Overall, we are happy with our progress. While it is difficult to win over people for any early-stage project, we are seemingly able to find (and convince) the right kind of people. Almost certainly, however, a working prototype would help to get our ideas across much more effectively. And exactly that is what we’re after.
We’ve spent the last days finally catching up with the absolute chaos that has been 2024 Q3 (and Q4 also, but more on that in the upcoming days). The good news is that we have found lots of solutions for the numerous problems we are actively working on. The bad news is that we are running late, at least compared to our initial timeline. Overall, we are increasingly dealing with uncharted territory, and we are learning to take on additional challenges with each and every day.
In terms of product, we have finished building the most important module of our GAMR architecture, and also added some more components to our Trading System. Our research has since taken the spotlight, and we are making good progress with our Update Generator model. The optimization has taken much longer than anticipated, however, and our data structures and data pipelines are posing a significant bottleneck. Dealing with this explosion in scope, we need to speed things up (we have a plan).
In terms of company, we have been confronted with changes in our team, seeing one of our co-founders leave for personal reasons. Setting us back at least a couple of weeks, we were fortunate enough to find a capable replacement on relatively short notice. Besides dealing with organizational overhead, we have continued planning our “Obliquid Financial Intellectual Property” (OFIP) subsidiary, trying to secure our intellectual property abroad. On a similar note, we have also prepared our international trademark registration at the most relevant locations world-wide.
Looking back, our most important learning has been that our product landscape is far too complex for only 2-3 people. On the one hand, we are simply moving too slow (on average). On the other hand, we are too susceptible to even the smallest things going wrong. We need to make adjustments.
Over the past 3 months, we have spent most of our time on starting up our product development, resulting in an early first version of our architecture. Working on both low-level problems (data structures, message protocols, …) and high-level problems (system design), we have developed a good understanding of our technical challenges and the time it will take to address them. Moreover, we have developed a better understanding of the implications that our organizational structure has for tax planning, intellectual property, and international strategy. The organizational structure not being fully implemented yet, we are keeping our plans on standby.
In terms of product, we have primarily been working on our exchange system and our trading system, dealing with a wide range of engineering issues. Up until this point, neither model design nor UX/UI design have been a priority. In this initial phase, we simply wanted to make a fast start and cover as much ground as possible (that is, achieve maximal output). This way, we are in a comfortable starting position for our prototyping phase which, due to its uncertain nature, does bear a significant risk of slowing things down.
In terms of company, we have primarily been working on our organizational structure, going through a large number of legal issues. Still, some questions remain to be answered. For example, we are yet to come up with a good way to install our “Obliquid Financial Intellectual Property” (OFIP) subsidiary abroad. When dealing with international tax and corporate law, good advice is generally hard to find (and even more so expensive).
Besides, we have also been preparing our product landscape (that’s a big one) and our content strategy (stay tuned).
While our product development is going to take some time (admittedly longer than we were initially hoping for), we are so far happy with our progress. In retrospect, it makes sense to have started with a deep-dive into exchange and trading system architecture, given that these also carry many implications for our model engineering. Since our complete organizational structure will generate a lot of overhead, we are holding back with the implementation. We do feel comfortable with our plans, however, and we know what to do once we decide to enter the market.
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 deep learning foundation model that you can essentially "play against", as though you were playing against the market (hence the name "GAMR"). 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.
Half a year into our start-up journey, we are (almost) done building our company and therefore finally able to shift more toward building our product. In this initial report, we want to outline the past and the future, where we have been and where we are going. Moving forward, we will report our progress on a quarterly basis. This way, we want to keep ourselves accountable, allowing to track our progress along the entire chain of reports.
In terms of product, we have primarily been working on our “Generative Adversarial Market Response” (GAMR) architecture. Over the past 2-3 years, we have gone from a small and relatively simple research project toward an increasingly large and sophisticated product. The development of our initial product iteration (our simulation platform) will take some additional time, with several hundreds of pages of documentation that are yet to translate into a working prototype. From here on out, our every action is geared toward achieving MVP status as soon as possible.
In terms of company, we have primarily been working on our organizational structure, designed to provide a safeguard for our intellectual property. We have made the conscious decision to address this issue as early as possible, as things tend get more complicated further down the road. With only one more step to go, we are going to install the “Obliquid Financial Intellectual Property” (OFIP) subsidiary to hold and secure most of our software. In the future, our organizational structure will grow with every additional business division (one division, one subsidiary).
In order to bridge the gap until our launch, we put particular emphasis on our content strategy. Simply speaking, we want to write longer-form content to build momentum and open doors. Having accumulated large amounts of useful information over the years, we plan on sharing that information in what we consider to be an early marketing initiative. Ultimately, the intention behind our content strategy is to grow our reach, so that enough people will know about our product once we launch.
Yes, you heard that right.
We are building a capital markets infrastructure provider (CMIP) for institutional market participants, and we will be operating entirely in the cloud. In anticipation of increasingly more capital markets infrastructure moving off-premise, our intent is to design technology at the frontier of cloud-native, ultra-low-latency (ULL) trading solutions, and to promote its wide-spread adoption in the trading industry. Our approach is from a perspective of technological feasibility, and we work overtime to make things a lot faster, not only cheaper.
We specialize in latency-critical systems and market microstructure research, and we put particular emphasis on deep learning models to support our trading operations. In the medium and long term, we will provide trading solutions for institutional market participants, allowing them to streamline their trading operations through means of the (public) cloud. In the meantime, we will build research and simulation solutions, working toward a disruption in foundation models for capital markets that is similar to what GPT-x has brought to other industries.
But why the name, you may ask.
Think of obliquid as oblique + liquid, a combination between the subtlety in (individual) trading strategy and the fluidity in (aggregated) trading outcome, together forming the complexity in capital markets. This relates to our mission insofar as we are building solutions that help navigate this complexity, and that make capital markets more accessible. Ultimately, the obliquid brand will represent all of our business areas which include, amongst others, our research services (OFRS), trading services (OFTS), and advisory services (OFAS).