Cole Page
Credit Analyst · cole.page.2027@anderson.ucla.edu · colehpage.com
SIF Portfolio Dashboard
A portfolio system I built for the UCLA Anderson Student Investment Fund: accounting off one transaction ledger, per-name research and notes, attribution and risk, and the weekly board report.
I built this and I'm the one who runs it. The screenshots here, and the demo behind them, run the same code against a synthetic fund, with made-up members, a made-up book and two years of generated history. No position or document on this page is real, and the one real name you'll come across is mine, on the seeded notes. The market data is live, though, so the prices are today's.
Why it exists
Before this the fund lived in spreadsheets, with the holdings in one workbook, the transactions in another, performance in a third and the analyst notes wherever each analyst happened to keep them, and four problems came out of that.
Every number got re-derived by hand each week, which meant two people could compute the same return two different ways and both defend it, and the cost basis drifted away from the transaction log because nothing forced the two to agree. Nobody could tell you who had changed a figure, or when, or what it had said before. And when a member graduated, whatever they knew about their names left with them.
A database solves the first three by itself, since it gives you one definition of each number, one place to write things down and a record of who wrote it. The fourth problem needed more than storage, though.
The idea I took from the buy side
At the credit fund where I interned, on the leveraged finance side, every issuer we followed had a research file going back years, full of underwritings, earnings reactions and event notes, all of them dated and attributed. Picking up a new name meant reading what the desk had thought three years ago and why that had changed. I came to think the file mattered more than any model in it, since a model gives you someone's conclusion, and the file shows you how they got there and where they were wrong.
Student funds throw that away every spring. The class turns over, and when an analyst graduates the reasoning leaves with them, so the next person to pick up the name inherits a ticker and a cost basis.
So in this system the notes live on the issuer, and each one carries a type (update, earnings, news, trim, close, question or other), an author and a date. That means a member who joins in 2027 can open a name and read what the fund thought about it in 2025, see what happened at each print, and find out why the position got trimmed.
If I could only keep one half of this system I'd keep the notes. With a custodian statement in hand you could rebuild the accounting in a week, but nobody can go back and reconstruct what an analyst was thinking in 2025.
What it does
The books. The accounting uses FIFO lots and runs off the transaction ledger, and it reconciles to the penny. Cost basis, realized and unrealized P&L and cash all get computed from that one ledger, so there's nothing to keep in sync. Concurrent edits are version-checked, which stops two admins from silently overwriting each other, and every change lands in a hash-chained audit log that you can verify end to end.
Research. Each name gets its own workspace with the price, fundamentals, filings, transcripts, estimates, peers and the full note history. When an analyst uploads a memo as a PDF, the thesis gets pulled out of it automatically. Price targets carry an up case and a down case, and they're versioned, so if you pull up a report from March you see March's targets.
Compliance. The checks run against the sections of the fund's own policy, which cover sleeve drift against target, the 15% gain and loss review band, cash policy and concentration, and hitting a price target or a downside case raises a trigger of its own. There's also a separate set of data-health checks that watches the platform itself and says plainly when a number shouldn't be trusted.
Performance and risk. Returns are measured against a sleeve-weighted blended benchmark. There's Brinson attribution by sleeve, by sector and by individual name, plus active share, tracking error, value-at-risk and a correlation matrix built from several years of daily security returns.
The board report. The report writes itself out of the books every week, and because coverage assignments and price targets are both time-versioned, an old week regenerates exactly as it stood at the time.
What it does not do yet
The books reconcile to the transaction ledger, but they don't reconcile to a custodian statement, which means the platform can prove it's internally consistent and can't prove it matches the broker. Weekly statement and NAV reconciliation is the next thing I'd build.
Several of the risk analytics ship switched off. The real fund only has months of return history, and a Sharpe ratio computed on twelve weeks is decoration, so those turn on when the data supports them. The benchmark's sector returns also use a broad-market proxy instead of the actual index constituents, which holds up at the sleeve level but gets too coarse below it.
How it is built
The stack is Next.js 16, React 19, TypeScript, Postgres through Prisma and Tailwind, and it's deployed on Vercel. There are thirty-five tables, twenty member-facing tabs and eight admin ones, and around a thousand unit tests that run as part of the build itself. Market data comes from a commercial provider and gets cached per endpoint, so quotes stay current without burning through the rate limit.
The constraint I designed around was accuracy, ahead of speed and ahead of how the thing looks. Every metric has exactly one function behind it, tested against fixtures, and if two routes ever compute the same number two different ways, that's a bug and it gets fixed before anything else ships.