What PortfolioPenguin does
PortfolioPenguin is a portfolio analytics engine inside Trunk, TB’s primary monorepo. It ingests pricing, fundamentals, holdings, and other financial data, runs it through a multi-stage pipeline, and publishes analytical tables that other applications consume.
The pipeline uses dlt (data load tool) for ingestion and dbt (data build tool) for transformation, with DuckDB and MotherDuck as the analytical database layer. The result is a set of normalised, query-ready datasets that power P&L attribution, risk factor analysis, and downstream analytics across the firm.
P&L attribution
P&L attribution answers a deceptively simple question: where did returns come from?
In practice, that means decomposing portfolio performance into its constituent parts—sector allocation, instrument selection, currency effects, and timing—so the investment team can distinguish skill from luck, and deliberate positioning from accidental exposure. The technology does not make the investment judgement; it surfaces the data that makes informed judgement possible.
PortfolioPenguin processes this at daily granularity, which means the team can track how attribution shifts over time rather than waiting for monthly or quarterly snapshots. When a position moves, the system can show whether the return came from the thesis playing out or from an unrelated market factor.
The table below is schematic only: row labels illustrate the shape of a typical attribution breakdown. It does not describe a real portfolio, period, or magnitude—figures are omitted so nothing here can be read as performance data.
| Effect bucket (illustrative) | What the row is for |
|---|---|
| Sector allocation | Return attributed to overweight or underweight versus a reference mix at sector level |
| Instrument selection | Return attributed to which names were held within a sector bucket |
| Currency | Return attributed to reporting-currency translation and cross-currency positions |
| Timing / residual | What is left after the other rows; flags drift between rebalance points and other timing effects |
One recurring question the workflow supports is which bucket moved when headline P&L shifts between two dates—for example, whether a change lines up with a deliberate sector tilt, a reshuffle of names inside a sector, or translation effects—so discussion can start from a shared decomposition rather than from ad hoc extracts.
Risk factor analysis
Risk analysis at TB is about understanding what the portfolio is actually exposed to, rather than what it was designed to be exposed to.
PortfolioPenguin surfaces risk factors across the portfolio so the team can see concentrations, correlations, and exposures that might not be obvious from looking at individual holdings. That matters because portfolios develop unintended exposures over time—two apparently different positions might share the same underlying risk factor, or a hedge might have drifted from the thing it was meant to hedge.
The analytical tables PortfolioPenguin publishes make these patterns visible. The team uses them to ask questions like: what happens to the portfolio if interest rates move? Where are we most concentrated? Which risks are deliberate and which are incidental?
How the data flows
The engineering challenge is less about any single transformation and more about keeping the whole sequence correct. PortfolioPenguin’s pipeline has multiple stages, and ordering matters. If instrument mapping runs before upstream data loads finish, the result is not obviously broken numbers—it is plausible numbers, which is worse. Catching that kind of error requires careful pipeline design and testing, not just monitoring the final output.
Once PortfolioPenguin’s pipeline completes, it publishes its production data through a MotherDuck share. Other applications—such as ProfitPelican, which builds its own analytical views on top—can query this data directly without maintaining separate copies. That keeps duplication low, but it also means schema changes travel quickly across application boundaries. A change in PortfolioPenguin’s output schema can quietly affect downstream consumers if the contracts between applications are not well managed.
This cross-application data dependency is a live engineering problem. The team uses shared libraries for connection setup and sandbox lifecycle, and CI/CD pipelines are sequenced so that downstream applications rebuild after PortfolioPenguin’s data is fresh. But keeping those contracts reliable as both applications evolve remains an area of ongoing work.
What this means in practice
The analytics PortfolioPenguin provides are not a reporting dashboard that someone checks occasionally. They are the quantitative foundation that the investment team uses day-to-day to understand their portfolio. When the system works well, it means the team spends less time assembling data and more time interpreting it.
How this shows up: When attribution and risk views are assembled ad hoc from different cuts and cadences, the same portfolio question can get different answers depending on timing and source. PortfolioPenguin’s daily granularity and published analytical tables give the investment team a single pipeline-backed layer for P&L decomposition and risk-factor analysis, so discussion can focus on what changed and whether it matches intent rather than on reconciling inconsistent extracts.
The technology is still being refined—pipeline correctness, cross-source instrument mapping, and staging environments that let a pull request test against isolated data rather than the live pipeline are all active areas of development. The goal is not a finished product but a system that keeps getting more reliable and more useful.