Floatline

Inspiration

In the retail banking world, most automated savings tools rely on primitive logic: transferring a static $50 every month or rounding up purchases. Meanwhile, institutional corporate treasuries utilize dynamic sweep accounts and tax-aware convex optimization to manage liquidity continuously. I wanted to bridge this gap. My inspiration for Floatline was to build a "self-driving treasury" for personal wealth—an engine that treats a standard consumer checking account like a corporate liquidity pool, autonomously sweeping excess cash into the market while utilizing quantitative rebalancing to minimize tax drag.

What it does

Floatline is an automated liquidity engine and tax-aware portfolio optimizer. It continuously monitors daily banking activity using the Capital One Nessie API. Instead of letting cash sit idle, Floatline operates on a dynamic threshold model. When the checking balance exceeds a defined operational buffer, the system automatically sweeps the excess capital into a brokerage account.

Once the capital is swept, Floatline executes algorithmic portfolio rebalancing. Rather than executing naive market orders that trigger massive capital gains taxes, the engine evaluates the portfolio at the tax-lot level. It utilizes a HIFO (Highest In, First Out) strategy to harvest capital losses, mathematically optimizing trades to return the portfolio to its target allocation while actively minimizing the user's tax liability.

How I built it

I engineered Floatline as a cohesive full-stack application optimized for real-time telemetry:

• Backend: Built with FastAPI (Python) to handle the control logic, Nessie/Alpaca API integrations, and the optimization math.
• Database (Tiger Data): Used TimescaleDB to handle high-frequency time-series data, specifically for tracking balance snapshots, transaction histories, and simulated tax-lot arrays.
• Frontend: Built with Astro and React. I utilized Recharts connected to a Server-Sent Events (SSE) stream from FastAPI to plot live portfolio adjustments without polling.
• Infrastructure: The entire stack is containerized using Docker Compose and deployed on a Vultr VPS (floatline.biz via Porkbun), with Caddy acting as a reverse proxy for automatic Let's Encrypt SSL.

To achieve tax-aware rebalancing, I implemented a convex optimization algorithm. The objective function minimizes both the portfolio's tracking error from its target weights \(\mathbf{w}^*\) and the tax liability incurred from selling specific historical tax-lots:

$$ \min _ { \mathbf{x} } \left( \alpha || \mathbf{w} + \mathbf{x} - \mathbf{w}^* || _ { 2 } ^ { 2 } + \beta \sum _ { j=1 } ^ { N } \tau _ { j } \Delta L _ { j } \right) $$

where \(\mathbf{x}\) represents the trade vector, \(\Delta L_j\) is the amount of tax-lot \(j\) liquidated, and \(\tau_j\) is the tax penalty associated with that specific lot based on its cost basis.

Challenges I ran into

The biggest hurdle was a strict limitation within the Alpaca Paper Trading API. The sandbox environment permanently locks all new accounts at a default $100,000 cash balance and does not support ACH deposits via their API. This meant my Capital One Nessie sweeps couldn't physically deposit cash into Alpaca.

If I simply queried Alpaca for the portfolio_value, my dashboard graph remained completely flat—Alpaca was just converting its pre-existing fake cash into ETFs. To solve this, I engineered a virtual cash flow handler using TimescaleDB to track the swept capital. Then, I rewrote my Alpaca API wrapper to iterate through the /v2/positions endpoint, dynamically calculating the true invested balance using:

$$B_{brokerage} = \sum_{i=1}^{n} P_i \cdot V_{i}$$

where \(P_i\) is the share quantity and \(V_i\) is the current market price of position \(i\). This allowed my frontend to accurately graph organic portfolio growth from $0 upward. I also had to debug a stubborn reverse-proxy crash caused by passing invalid auto_https directives in my Caddyfile.

Accomplishments that I'm proud of

I am incredibly proud of designing and deploying a fully containerized, production-ready architecture on a Linux VPS from scratch during a hackathon. Furthermore, successfully translating complex quantitative finance concepts—like tax-lot array manipulation and drift-band optimization—into a tangible, consumer-facing banking product was a massive technical milestone for me.

What I learned

This project pushed me deep into time-series data modeling with TimescaleDB, which proved to be incredibly powerful for managing chronological financial snapshots. I also gained practical experience managing real-time data streams via SSE, configuring Caddy reverse proxies, and handling the nuances of HIFO accounting logic within a brokerage wrapper.

What's next for Floatline

Currently, Floatline sweeps into a single taxable brokerage. Next, I plan to expand the architecture into a 4-category engine (Checking, Savings, Taxable Brokerage, Roth IRA). By integrating "asset location" algorithms, Floatline will automatically route high-growth ETFs into the tax-free Roth IRA until the annual contribution limit is mathematically maximized, only overflowing excess liquidity into the taxable harvester account.

Built With

• alpaca-api
• astro
• caddy
• docker
• docker-compose
• fastapi
• linux
• nessie-api
• postgresql
• python
• react
• recharts
• rest-api
• server-sent-events
• timescaledb
• typescript
• vultr