Why we built our own treasury engine
A look at the trade-offs that pushed us to build the cash-management infrastructure ourselves instead of routing to a third-party fund operator.
For most of Northbank’s history, our treasury product was a thin layer over a third-party money market sweep. It worked. Customers earned yield. We did not have to operate the underlying funds. The math closed.
Last year we replaced it with infrastructure we run ourselves. This post is about why.
What the third-party model did well
Routing customer cash to a partner fund operator is an honest model. They handle the complicated parts — fund operations, NAV calculation, broker-dealer relationships, regulatory reporting. We handle the experience: the dashboard, the controls, the audit trail. For a long time, that division of labor was correct. We were not, by any measure, the team best positioned to run a fund.
It also let us ship treasury years earlier than we otherwise could have. A customer who wanted yield on operating cash in 2022 did not have a great answer at most banks. We had one because we did not have to build it.
Where it stopped working
Three problems crept up over time.
First, latency. Every product decision we made about treasury had to be ratified by our partner’s operational tempo. A new policy control we wanted to ship took twelve weeks to roll out, not because the engineering was hard but because the partner’s release cycle was monthly. We were the limiting factor on neither end.
Second, observability. Our customers asked, increasingly, for views of their treasury position that we could only provide with a delay. The partner had the data. They did not have it in the shape our dashboards needed. Translating it took a daily batch job and a small team of people whose work was, in retrospect, an outage waiting to happen.
Third, margin. This one took longer to surface. The partnership had a stable economic structure that priced our scale at small. As we grew, the structure stayed the same — and our customers were paying for revenue that did not, in any meaningful sense, fund the work that served them.
Building it ourselves
The decision to build was not, in the end, dramatic. It was a quiet conclusion at a quarterly business review where the same three problems showed up on three different slides.
The build itself was the harder part. We hired ahead of the work — three engineers and a treasury operator with prior fund experience — and we ran the in-house engine in shadow mode, against the partner, for six months. The numbers had to match to the cent. They did, on the third try. The first two were instructive failures.
What we did not anticipate
The biggest surprise: customer trust changed. Customers we had been working with for years asked, gently but pointedly, whether we were sure we could run this ourselves. They were right to ask. Treasury infrastructure is not a place to learn on the job.
The answer was not just to say yes. The answer was to invite them in. We gave a small group of customers access to our internal dashboards during the shadow period. We sent them detailed reconciliation reports. We were, in some cases, more transparent about our internal numbers than we had been about the partner’s. Trust returned, in large part, because we had stopped treating it as a deliverable and started treating it as a conversation.
Where this goes
We are now running the engine in production for the full customer base. The latency problem is gone. The observability problem is gone. Margin closed in the way we hoped.
We are not, however, advocating that every fintech build their own treasury infrastructure. Most should not. The decision was right for us because we had grown into a position where we could do the work better than we could buy it — and we had the patience to spend a year building before we shipped a feature out of it.
If you are evaluating the same trade-off, the question is less can we build it and more can we operate it well for the next ten years. If the answer is no, the partner model is honorable work.