Treasury features are sold as add-ons. They should be sold as infrastructure.
If you run a payfac or an AP platform, you already own the most important moment in your client’s financial day: the moment cash moves. But odds are you are leaving the stickiest layer on the table. Cash forecasting, multi-account visibility, instant issuance — these are not product extensions. In my view, they are the retention architecture that keeps commercial clients from leaving.
I have spent most of my career building payments infrastructure that sits inside other platforms, and the pattern repeats: the clients who depend on me only for payment execution are always shopping. The clients who see their entire cash position inside my dashboard, who run their daily forecast off my data, who issue a card instantly when they need it — those clients do not leave. Not because they love the product. Because leaving would break their operating rhythm.
The PYMNTS analysis on trapped cash makes the case from the demand side. Visibility is largely solved for cutting-edge finance teams — dashboards, TMS connectivity, account rationalization. But usability remains broken. CFOs can see cash across jurisdictions and cannot move it freely. They are stuck waiting on regulatory clearances, entity approvals, tax opinions, local banking cutoffs, the sausage-making of cross-border operations.
This is your wedge. If you are a platform that already handles payments, adding treasury management is not upsell — it is deepening the moat. The client is already routing AP spend through you. When you also give them visibility into the cash they will need next week, and the ability to forecast based on payables already in flight, and the instant card to bridge a timing gap, you have moved from vendor to operating system.
In every platform relationship I have been part of, payment execution alone became a transaction relationship. You can be beaten on price, on speed, on a slightly better underwriting offer. But forecasting, visibility, and instant issuance are daily-use features. They become habits. The finance team builds their morning workflow around the cash position you show them. The CFO references your dashboard in board meetings. Switching means rebuilding that workflow, retraining the team, losing the historical data and the forecast accuracy that compounds over time.
The market is already signaling this. I have watched a stablecoin issuer acquire a treasury platform — what I read as the same playbook a bank runs: use treasury as the entry point to capture corporate deposits, then earn yield on the float. The treasury layer is not the side product — it is the on‑ramp. I have watched this happen in domestic B2B payments: when a competitor owned the treasury view, they eventually owned the AP routing. That convergence is where the acquisition and partnership pressure will land — between ERP vendors, treasury management systems, and B2B payment networks that can actually operate in the messy middle where visibility ends and execution begins.
This assumes you have the bank connectivity and regulatory scope to actually hold the treasury view. If you do not, the first move is not a product roadmap decision — it is the partnership, licensing, or banking stack that gets you there. In my experience evaluating payfac stacks, most lack multi‑account bank feeds, cannot legally hold or forecast against client funds in the required structure, and underestimate the operational lift of entity‑level treasury across jurisdictions. Build or buy is a real question, but what is not optional is owning the view.
If you are building or investing in a platform that serves commercial clients, here is the test I would run: look at your product roadmap and separate features used daily from features used monthly. The daily‑use features determine whether the client builds habits around your platform or treats it as a back‑end utility. Treasury features, done right, win the daily‑use category because I have found that cash visibility becomes compulsive. Nobody ignores the question of whether they have enough cash tomorrow.
The convergence is already happening. CFOs expect their payment platform to show them cash position, not just transaction history. They expect forecasting based on real payables data, not imported spreadsheets. They expect to issue a card instantly to capture an opportunity or cover a gap. If you do not offer it, someone else will — and once their treasury layer is installed, your payment volume follows.
I am watching this closely because it sits at the intersection of what I built into for years: payments infrastructure that becomes embedded enough to define how the client operates. If you are building treasury features into a platform, or deciding whether they deserve priority on the roadmap, I would like to hear what you are seeing.