Why stitch together five trade finance vendors when one data model does it?

By Saurabh Goyal, Founder & CEO of Phlo Systems. Published 1 October 2026.

In September 2026, two established trade finance vendors announced a partnership: one platform's trade-document and KYC workflow wired into the other's bank-led processing system, over an open API layer. Read as a product announcement, it is unremarkable — vendors partner constantly. Read as a pattern, it is the trade finance software market's default answer to a question it keeps getting asked: when a point solution needs to cover more of the deal lifecycle, the industry reaches for an API integration to another point solution, not a single data model that already covered both halves.

The 30-second answer: trade finance software is built as point solutions — LC lifecycle in one platform, collateral and KYC in another, facility and covenant tracking in a third — because that is how the lender side of the market grew: one vendor per workflow, integrated after the fact when customers demanded more coverage. That works well enough for a bank integrating two of its own back-office systems. It works much less well for the commodity trader CFO on the other side of four or five separate lender relationships, each running its own version of this stitched-together stack, because the reconciliation burden the vendors solved for themselves (bank-to-bank, system-to-system) simply moves downstream to whoever has to make sense of all of it: the borrower.

What actually changed, and why it matters beyond the two vendors involved

The specifics of any one partnership matter less than the shape of it. A trade-document and counterparty-KYC platform gets wired into a bank-led trade processing platform via an open API, so that a transaction originated in one system can pass through to the other without a human re-keying it. That is a real integration, and a genuine improvement over the alternative (a human re-keying it). But it is also an admission: neither platform's own data model covered the full transaction lifecycle on its own, so the fix was to connect two separate data models after the fact rather than have had one in the first place.

This is not a criticism of either vendor specifically — it is how the lender-side trade finance software market has grown for two decades, through acquisition and partnership rather than a from-scratch unified build. The market structure rewards it: a bank integrating two systems it has separately paid for is a solvable, well-understood IT project with a clear owner on each side. The same pattern looks very different from the other side of the transaction.

Where the reconciliation burden actually lands

A mid-market commodity trader with four or five active lender relationships is not dealing with one stitched-together vendor stack — they are dealing with four or five of them, each potentially stitched together differently, each with its own portal, its own document format, its own notion of where a facility's covenant headroom stands today. None of those vendors' API integrations with each other help the trader, because the integration solves the bank's internal reconciliation problem, not the borrower's problem of holding all four or five relationships in a single coherent view.

	Lender-side point solutions, API-stitched	A single data model, borrower-side
Who the integration serves	The two vendors' shared bank customer	The trader holding multiple lender relationships
What happens when a new lender is added	A new, separately-integrated stack to learn	The same model, one more facility added to it
Where facility, collateral, and FX data reconcile	Inside each bank's own stitched stack, invisibly to the borrower	In the trader's own book, visible the moment anything changes
Who does the cross-lender reconciliation work today	Nobody — it falls to whoever at the trading firm rebuilds the picture by hand	The system, continuously

Why "integrated" and "connected by API" are not the same claim

An API connection between two platforms means data can move between them without manual re-entry. It does not mean the two platforms share one definition of a facility, one definition of a covenant, or one timeline of events. Two systems can be perfectly API-connected and still disagree, subtly, about what "available headroom" means on a given day, because each still keeps its own version of the truth and the API is only moving a copy of it across. A unified data model has no second copy to disagree with — there is one record of the facility, one record of the drawdown, one record of the collateral position, and every view of it (covenant tracking, FX exposure, cash flow forecast) reads from that same record rather than from a synchronised copy of it.

For a CFO deciding how to evaluate trade finance software, that distinction is the practical question to ask a vendor, not a theoretical one: when two of your modules talk to each other, are they reading the same record, or are they two records kept in sync by an integration? The answer determines whether a discrepancy between, say, facility utilisation and cash flow forecast is even possible to have in the first place, or whether it is possible and someone has to notice it.

What this means for a trader managing multiple lender relationships

1. Ask each lender what their own stack is actually built from. A lender whose own platform is itself several vendors stitched together by API is not a reason to avoid that lender — most of the market looks like this — but it is a reason not to expect that lender's system to be the place a trader goes for a single cross-facility view.
2. Keep the cross-lender, cross-facility view on the trader's own side, not any one lender's. No lender's platform, however well integrated internally, has a reason to show a borrower's position across other lenders. That view only exists if the trader's own system holds it natively.
3. Treat "we integrate with X" in a vendor's sales pitch as a starting question, not a closing one. Ask specifically whether the integration shares a data model or synchronises two separate ones — the operational difference shows up exactly when something changes quickly, which is the moment it matters most.

Frequently Asked Questions

Does a trade finance vendor partnership like this benefit the commodity trader directly?

Usually not directly. These partnerships typically solve a reconciliation problem between the vendor and its own bank customer's internal systems. They do not give a borrower a single view across multiple lenders, because no single lender's platform has a reason to show a borrower's position at a different lender.

Is an API integration between two platforms the same as having one data model?

No. An API integration moves data between two systems that each keep their own record of it. A single data model has one record that every view reads from. The practical difference shows up when something changes quickly and the two synchronised copies have not yet caught up with each other.

Why does the trade finance software market look like this, rather than being built as one system from the start?

Lender-side trade finance software has grown over two decades through acquisition and partnership, one workflow (LC lifecycle, KYC, collateral, covenant tracking) at a time, typically sold to banks rather than to the borrowers using the facilities. Partnering two existing platforms is a faster way to add coverage than rebuilding either one from scratch.

What should a CFO with several lender relationships actually do about this?

Keep the cross-lender, cross-facility reconciliation on a system the trader itself controls, rather than expecting any one lender's platform — however well it integrates with other vendors — to provide that view.

How Phlo Systems helps

finPhlo holds facility, covenant, collateral, FX, and cash flow data for every lender relationship in one data model, not a set of modules synchronised by API. A trader running four or five facilities sees one current picture across all of them, because there is one record behind it, not several kept in step with each other. See how finPhlo tracks multi-lender trade finance.

---

Related reading:

• Best Trade Finance Software for Commodity Trader CFOs in 2026
• What is tokenized trade finance, and how does it close the $2.5 trillion trade finance gap?
• How does FX hedging work for a commodity trader with mismatched currencies?

Saurabh Goyal is the Founder & CEO of Phlo Systems. He spent 12 years building CTRM and ERP systems for global commodity trading houses before founding Phlo in 2016.