Decision logic, and the systems that run it

A documented, replicable investment process is what separates disciplined investing from opportunistic speculation — and what an institution can actually be held to. The paper sets one out end to end: what a digital asset portfolio should hold, and how you actually get there. It specifies the whole process — defining the investable universe through screening criteria, integrating fundamental, quantitative, technical and sentiment-based signals into a Black–Litterman construction engine, and turning the resulting weights into executed trades. Published in the CVA Research Journal on 17 December 2025, with Dominik Stiftinger-Lang, Jérôme Benathan and Hugo Doering.

I wrote two of its chapters. Portfolio construction covers the data layer — market capitalization and liquidity, price and volume series, protocol analytics, sentiment indices — and how those heterogeneous inputs become views with associated uncertainty in a Black–Litterman posterior. The engine underneath is my implementation: the base Black–Litterman model and the feeding of its posterior returns into the robust optimizer, with the partner's signals and the choice of views adapted for the paper. Rebalancing execution formalizes what a reallocation costs, shows why routing every position through one common asset is suboptimal where assets are quoted directly against each other, develops the shortest-path formulation and its practical limits, and reports the simulation study of 100 reallocations per portfolio size, from four to sixteen assets over a 24-asset investable universe — simulations run with the cost-optimal rebalancing engine described below, which the chapter documents rather than re-implements. In the framework's backtest — weekly rebalancing, January 2021 to September 2025 — the fee-adjusted Black–Litterman strategy earned an annualized return of 77%, 21 percentage points a year above the CCI30 index, with beta below one and the shallowest maximum drawdown of the twelve strategies compared. The framework is deliberately modular: each stage can be lifted out and used on its own, or as a building block for a product.

• Black–Litterman
• Portfolio Construction
• Rebalancing Execution
• Technical Writing

Read the paper (PDF, 32 pages)

Investors decide whether to stay invested on the strength of a handful of numbers, and those numbers have to survive being questioned by someone who did not compute them. Every one of them depends on choices that are invisible in the result. I built the analytics layer that turns transaction and price history into those figures: annualized and time-weighted returns, volatility, variance and semivariance, downside deviation, Sharpe and related risk-adjusted ratios, maximum and average drawdown, and performance against a market index benchmark whose constituent set is configurable.

The substance is in the definitions. Metrics are derived from relative daily returns rather than absolute portfolio values, so deposits and withdrawals don't distort them; day boundaries are fixed in UTC so accounts in different time zones aggregate consistently; and cash flows arriving without a record — staking rewards, airdrops, internal transfers — are attributed explicitly, since otherwise they register as phantom returns. Beneath sits the query layer that aggregates positions, transactions and prices out of Postgres into daily series, indexed so a chart can be redrawn on request rather than precomputed nightly, and the chart series and summary table are generated from the same source — two code paths producing nearly equal numbers is a support problem. The library exists twice, in Go for production and Python for research, with unit tests serving as the specification.

• Go
• Python
• PostgreSQL
• Pandas
• NumPy

An automated trading system is only as trustworthy as the evidence that it is working. I built the monitoring and reporting layer that provides it: dashboards over time-series metrics and aggregated logs for the live view, generated reports for the record. The two answer different questions — whether the system is behaving right now, versus what it did over a period, in a form that can be filed and compared.

For the arbitrage strategy the panels followed the money rather than the machine: cumulative quote profit and traded volume per pair, transfer volumes and fees between venues in a common quote currency, relative transfer fees per asset over time, and a table of total transfer cost — number of transfers, absolute volume, absolute and relative cost — per asset. Transfer cost is what quietly decides whether an arbitrage strategy is profitable, so it earned as much dashboard space as the profit itself. The bot underneath was one I also maintained and extended: incremental work on the execution path, partial fills and venue error semantics, converting silent failures into explicit ones.

• Grafana
• Loki
• PostgreSQL
• TimescaleDB
• Time-Series Data
• Automated Reporting

Each venue added is more liquidity to trade against, better prices to route through, and another market clients can hold assets on — without a single change to the logic above. Every exchange offers the same idea, place an order and hold a balance, through a different interface with its own names, rules and rounding, and I own the adapters that hide those differences. Bringing up a venue means mapping its instrument and symbol scheme, precision and lot-size rules, fee schedule and fee currency, account modes, order types and time-in-force semantics, and its balance model onto the internal interface the rest of the platform is written against, so routing, rebalancing and reporting stay venue-agnostic.

Market data is the other half: subscribing to order-book and user-data streams, verifying sequence continuity and resynchronizing after a gap, falling back to REST for history, and staying inside per-endpoint rate limits. Order state is reconciled continuously rather than assumed, because a venue and a client eventually disagree. Most of the difficulty is in discrepancies that only surface under real conditions — reserved balances counted twice because frozen funds are reported differently, position limits expressed in contracts where the platform reasons in notional, a data channel gated behind a paid tier — so integrations are validated against the live venue at small size before they are trusted with real allocations. Submission is idempotent, because a retry that the venue already accepted is an unintended second position. The most recent integration extended the platform beyond spot into derivatives, adding margin providers and position-tier bounds.

• Go
• REST & WebSocket APIs
• Concurrency
• Reconciliation

Every rebalance costs money in fees and spread, and that cost comes directly out of return. This engine reduces it. The conventional approach sells every overweight position into one common asset — a stablecoin, the digital equivalent of holding cash — and buys the underweight ones back out of it. Each position then pays two spreads and two sets of fees. In digital asset markets that intermediary isn't required: assets are quoted directly against one another, and the cheapest path to a position being bought sometimes runs through one being sold.

I built the engine that finds those paths. The tradable markets are modeled as a directed graph — assets as nodes, trading pairs and inter-account transfer routes as weighted edges, weights derived from the fee schedule and quoted spread, balances valued against a common equivalent asset. A shortest-path search runs iteratively over that graph until the target allocation is met, yielding an ordered sequence rather than a set: orders must respect per-pair minimum sizes and precision steps, and each leg depends on its predecessor having settled, so the route has to be executable and not merely optimal. On top, the execution layer applies slippage adjustment and measures fill quality against the price the route was calculated at.

In simulation against the common-asset route, the method saved 9.4% of transaction cost on a four-asset portfolio and 19.1% on a sixteen-asset one, and was cheaper in 99 of 100 runs at that size. Path length never exceeded four hops in simulation or live execution, which bounds the slippage the extra legs can introduce. These simulations are native to this project — the engine itself ran them — and they are reported, together with the method, in the rebalancing-execution chapter of the published paper above.

• Go
• Graph Algorithms
• Dynamic Programming
• Smart Order Routing

The platform lets a firm manage client portfolios across several exchanges without anyone moving positions by hand — allocation, execution and reporting in one system rather than a spreadsheet and a set of exchange logins. Built as the company's internal tool from 2023, it opened publicly in 2025 and has been developed most intensively since — the busiest year of the codebase is the current one. As the company's co-founder and CTO I have been one of the main engineers on it since the beginning, working mostly on the decision logic — how a target allocation is derived, and how a rebalance converts it into a concrete, ordered set of instructions — and on the data model that logic reads from.

The platform has to know what is currently held, decide what should be held, and carry out the change. Architecturally that is a set of Go services separated by domain — account and order management, execution, scheduling, market-data import, analytics, an API layer — over a single Postgres system of record. Two decisions shape the rest. All venue-specific behavior sits behind an adapter interface, so domain services never learn which exchange they are dealing with. And long-running operations are modeled as durable workflows (Temporal) rather than request handlers: a rebalance is dozens of dependent orders across accounts taking minutes, so each step is idempotent and independently resumable, and a crash mid-sequence continues rather than restarting into duplicate orders.

The database carries the same requirement. Positions, transactions, funds, fees and derivative exposure are stored so any portfolio can be reconstructed as it stood at any past moment, which makes the schema closer to an append-only history than to current state — constraining migrations, which must evolve the model without discarding history, and access, which is scoped per service role. The platform has since grown from spot trading into derivatives, adding margin sizing, position tiers and a second class of reconciliation problems.

• Go
• PostgreSQL
• SQL
• Docker
• Temporal
• HashiCorp Vault & Consul

Genealograph lets someone document a family as it actually is — including the remarriages and step-relations most software refuses to represent — and print the result. Trees are assembled on a worksheet: people are added as nodes, connected through partnerships and lines of descent, annotated with biographical detail, then laid out and printed. Documents are serialized and restored through a dedicated I/O layer, and the interface ships with a German localization alongside English.

The decision that determines the rest is not modeling a family as a tree. People, partnerships and descent are separate object types with their own relations, so remarriage, multiple partnerships and children across them are ordinary cases rather than exceptions attached to a parent pointer. The editors follow from that structure, and so does the layout, which has to place a graph rather than a strict hierarchy. It is deliberately unmanaged: C++ with CMake, no runtime hiding object lifetime, building under both GCC and Clang.

• C++
• Qt
• CMake
• Qt Linguist

github.com/wolkensichel/Genealograph

Public research funding paid for a year of development that would otherwise have had to be financed out of revenue — and, because the work had to be specified and defended before an external committee, the architecture was argued before it was written. I secured the grant from the FFG, Austria's national research promotion agency, for an end-to-end portfolio management system for digital assets.

The project ran from April 2025 to June 2026 across five work packages: project management; extending the architecture to derivatives and staking; a theoretical and empirical analysis of risk-adaptive models for digital assets; dynamic portfolio optimization built on that analysis; and optimized multi-order execution in fragmented digital markets. Each carried its own deliverables and dated milestones, with cost and effort estimated line by line and the risks that would prevent delivery assessed up front. All five were delivered.

• Proposal Writing
• System Architecture
• Effort Estimation

View the project in the FFG database

This is how an analyst's judgement gets into a portfolio without anyone having to invent a number. Classical mean–variance optimization in Markowitz's sense needs an expected return for every asset, which nobody can supply honestly. Black–Litterman starts instead from what the market already implies and adjusts it with the opinions you can defend. I implemented the system in full, following Cela, Hafner, Mestel and Pferschy's formulation for ordinal information: views stated as ordering relations among expected returns rather than point forecasts, treated as stochastic, with the posterior conditioned on those constraints and estimated by importance sampling.

Around it sits the machinery that makes it usable. The optimizer's inputs are estimated robustly rather than taken as sample means: bootstrapped return paths with Theil–Sen and Huber regressions fitted to log growth, trimmed means and medians as cross-checks, and Student-t distributions fitted by maximum likelihood to feed the simulation and importance-sampling steps. On top come the equilibrium prior obtained by reverse optimization from market-capitalization weights, the view and view-uncertainty matrices, efficient-frontier asset selection, and a robust variant treating expected returns as lying within an uncertainty set — the plain Markowitz optimizer staying in as the reference. Calibrating the robust variant was curve- and parameter-fitting work of its own: measuring empirically how large the uncertainty set can grow before the solution degenerates, then fitting a distribution to the risk-seeking coefficient so its parameters could be derived from a family of fitted functions rather than chosen by hand. The backtest harness underneath measures against six baselines — buy and hold, uniform weights, minimum variance, maximum Sharpe, mean-best and random rebalancing — over rolling windows with bootstrapped return samples, and gives more attention to lookahead, survivorship and optimistic cost assumptions than to the optimizer itself. The construction engine of the published framework above builds directly on this work: the base Black–Litterman model and the use of its posterior returns inside the robust optimizer are this implementation, adapted for the paper by taking the asset-management partner's signals as views.

• Python
• NumPy
• SciPy
• Statsmodels
• Scikit-learn
• Jupyter

The method it builds on