The trade finance industry faces a persistent problem: fragmentation. Every platform claims to digitise trade documents – but without common standards, integration becomes a custom engineering project. Banks, shippers, insurers, and customs authorities operate on incompatible data models and APIs. This creates silos that make the whole network less valuable.
Interoperability is the constraint that prevents digital trade from scaling. A single platform cannot solve this. Instead, the industry is converging on a practical strategy: establish shared standards for data and APIs, then build focused tools that plug into this open ecosystem.
In an episode of On The Block, Espeo Software’s series on blockchain and decentralised technology, we explore how standards and APIs are reshaping trade finance infrastructure. The discussion covers which standards matter, how to evaluate platforms, and the governance patterns that actually work in practice.
Why interoperability is the scaling constraint
The fundamental insight is simple: standardisation enables scale. As one expert puts it,
“If every platform has its own data model and its own way to represent a bill of lading or an invoice or a certificate, then each integration is a mini-project. The industry has learnt that we first need shared standards for data and for APIs.”
– Przemysław Koper, CEO at Espeo Software
When platforms lack common standards, the cost of integration rises exponentially. A bank that wants to connect to five different trade platforms must build five different integrations. A shipping company linking to twenty banks faces twenty separate projects. This friction pushes organisations toward monolithic platforms – which then fail to capture the full trade network.
The economic incentive is clear: organisations that adopt open standards reduce integration cost and reach more counterparties. Those that build proprietary systems lock themselves into expensive, brittle architectures. Over the past five years, this logic has driven the industry toward consensus.
Standardisation is not about enforcing a single global platform. It is about defining common data formats and API contracts that allow specialised tools to coexist and interoperate.
What to standardise: documents, events, identities, and evidence
Trade finance involves four distinct standardisation challenges:
- Document schemas: Bills of lading, invoices, packing lists, certificates of origin, and other key trade documents must have agreed data structures. Without schema standards, validation and automated processing become impossible.
- Event streams: Trade workflows progress through events – shipment booked, goods received, certificate issued, payment cleared. These events need standardised representations so that multiple systems can react to the same signal.
- Identity and trust: Digital signatures, issuer verification, and custody chains require standardised identity systems. Without agreed identity standards, each platform must solve trust independently.
- Evidence and validation: Proof of compliance, risk scoring, and fraud detection rely on standardised data elements that validators can trust. This is especially critical for regulatory compliance.
The industry is making real progress on all four fronts. Industry bodies have published detailed specifications for what data should be in key trade documents. Standards organisations have published API specifications that define how platforms should communicate. And major carriers have committed to timelines for removing paper bills of lading from their operations.
The ICC Digital Standards Initiative and KTDDE as anchors
Two initiatives have become focal points for trade finance standardisation:
The International Chamber of Commerce (ICC) Digital Standards Initiative (DSI) brings together large banks, technology vendors, and trade bodies to define data standards for key trade documents. The ICC DSI is not a technology standard – it is an agreement on what information matters and how it should be represented.
Key Trade Documents and Data Elements (KTDDE) is the ICC DSI’s core output: a detailed specification of the data that should appear in bills of lading, invoices, certificates of origin, and other critical documents. KTDDE also defines how these documents relate to each other and to regulatory requirements.
Why these two matter
The ICC DSI and KTDDE have achieved what previous standardisation efforts could not: buy-in from the largest banks and shipping lines. When HSBC, ING, DBS, and Maersk agree on a standard, vendors have an incentive to implement it. When KTDDE is updated, the whole ecosystem has clarity on what “complete” and “valid” mean.
These standards are not perfect or complete. They are living specifications that evolve as the industry learns. But they are authoritative enough that software vendors now use them as a baseline, and major carriers are structuring their operations around them.
eBL interoperability: what standards-based means
Electronic bills of lading (eBL) are the test case for trade finance standardisation. An eBL is interoperable when it can be issued on one platform, transferred through a different platform, and accepted by a third platform – without manual intervention or re-entry.
This is harder than it sounds. It requires:
- A standardised data model for the eBL content itself (addressed by ICC DSI / KTDDE)
- A standardised format for the electronic signature and chain of custody (addressed by standards like DCSA, developed by the Digital Container Shipping Association)
- A standardised way to transfer the eBL from one custodian to another (e.g., via a notary or endorsement mechanism)
- A way for the receiving platform to validate the eBL without calling back to the issuing platform
When these elements are absent, eBL platforms become isolated islands. Each claims to support eBLs, but they cannot interoperate. A bank that receives an eBL from Platform A must have a separate relationship with Platform A to validate or accept it. This defeats the purpose of standardisation.
True eBL interoperability means:
This is not yet universal, but it is the direction travel is headed. The DCSA has published standards for eBL interchange. Major carriers have publicly committed to eBL timelines. Banks are building their systems to recognise eBLs from multiple sources.
API patterns: point-to-point, hub, and shared services
Interoperability is not just about data standards – it is also about how systems communicate. Three API patterns are emerging in trade finance:
1. Point-to-point APIs
Traditional bilateral integration between two platforms. A bank and a carrier might build a direct API integration to exchange eBLs and shipment status. This works for high-volume, stable relationships, but it does not scale across the ecosystem.
2. Hub models
A central platform becomes the integration hub. All other platforms connect to the hub via standard APIs. The hub is responsible for translating between different data models and orchestrating workflows. Examples include some trade finance networks that position themselves as the central node.
Hub models work but create a chokepoint. If the hub goes down, the entire network stalls. If the hub’s business fails, participants must scramble to rebuild their integrations elsewhere.
3. Shared services and APIs
Rather than a single hub, the ecosystem uses multiple specialised services that talk to each other through standard APIs. One service handles document validation and compliance. Another handles risk and fraud scoring. A third handles payments and settlement. Banks access these services via existing networks such as SWIFT, without needing to join a big new platform.
“Banks can access such services via existing APIs and networks such as Swift. No need to join a big new platform.”
– Przemysław Koper, CEO at Espeo Software
This shared services pattern is the most resilient and flexible. It avoids the chokepoint risk of a single hub, and it allows banks and carriers to choose which services they adopt.
Risk and validation services as interoperable components
One of the highest-value use cases for interoperable trade finance infrastructure is validation and risk assessment. Consider a bank that wants to automate its trade compliance review:
- The bank receives a eBL from a carrier on Platform A
- The bank uses a separate validation service (running on Platform B or as a standalone API) to check the eBL against sanctions lists, anti-corruption databases, and internal rules
- If the validation passes, the bank automatically releases payment via its settlement network
This workflow only works if the validation service can accept a eBL from any issuing platform. In other words, it requires standardised eBL formats and APIs.
Risk and validation services are becoming interoperable components for a simple reason: they add value at the ecosystem level. A validation service that only works with one eBL platform has limited reach. A validation service that works with all standards-based eBLs becomes a utility that many banks will purchase.
The waterfall effect
When major carriers change how they operate, everyone downstream must adapt. This is not optional – it is commercial pressure. Carriers moving to eBL force banks and insurers to accept eBLs. Banks standardising on a particular eBL format force validation services to support that format. This waterfall effect accelerates standardisation adoption across the entire network.
“When the companies that actually move the cargo change how they operate, everyone else has to adapt, including banks and insurers.”
– Przemysław Koper, CEO at Espeo Software
The emerging architecture: a network of networks
The future of trade finance infrastructure is not a single global platform. It is a practical ecosystem of specialised networks that interoperate via standards:
“We will see a network of networks. Some will focus on documents, some will focus on fraud and risk, some will focus on payments and settlements. And they will talk to each other through standards and APIs.”
– Przemysław Koper, CEO at Espeo Software
This architecture looks like this:
Each layer communicates with the others through standard APIs and data formats. This allows a bank to assemble a tech stack from multiple vendors without being locked into a single platform.
How to select platforms: a practical procurement checklist
For banks, shippers, and other trade finance participants, the key question is: how do I choose technology vendors and platforms that will remain relevant as standards evolve?
Here is a practical checklist:
The underlying principle is this: avoid vendor lock-in by choosing platforms that commit to open standards and interoperability. A platform that locks you in via proprietary data formats or closed APIs will become a liability as the industry matures.
A pragmatic rollout plan: start narrow, then connect
Most organisations should not wait for a perfect ecosystem before starting. Instead, a pragmatic approach is:
Phase 1: Start with high-impact documents
Focus on the documents and workflows that create the most manual effort or risk in your business. For a bank, this might be bills of lading and invoices. For a carrier, it might be shipment status and eBLs. Choose one or two workflows, not the entire trade universe.
Phase 2: Use standards-based tools
Build or buy technology that is explicitly standards-based. Avoid tools that claim to be “industry solutions” but use proprietary data models. Prefer platforms that publish APIs and participate in standards bodies.
Phase 3: Integrate with your existing systems
Use standard APIs to connect trade-specific platforms to your core banking, ERP, or operations systems. This may require custom integration code, but it should use well-defined API contracts, not custom ETL processes.
Phase 4: Add specialist services
Once you have core workflows running, layer in specialist services for validation, risk, compliance, or settlement. These should integrate via standard APIs with the systems you already have.
“Don’t wait for one magic platform. Instead, look for focused tools that can plug into the systems you already have. Start with the documents and risks that matter most to your business. And make sure whatever you build or buy is based on open standards and can interoperate.”
– Przemysław Koper, CEO at Espeo Software
This approach avoids the two extremes: waiting indefinitely for a perfect platform, or rushing to join a large ecosystem that may not fit your business model.
Governance beats technology
One final point deserves emphasis: the architecture of the trade finance network depends less on technology than on governance.
“Governance beats technology. Who controls the network matters as much as what runs under the hood.”
– Przemysław Koper, CEO at Espeo Software
A well-designed API standard matters. But it matters even more who decides to update the standard, how disputes are resolved, and whether the governing body has legitimate authority in the industry.
This is why the ICC DSI and DCSA have had real impact: they have legitimacy. Major banks and carriers participate in their decision-making. Standards published by these bodies are treated as authoritative.
By contrast, a standards body controlled by a single technology vendor or a small club of insiders will not gain adoption. Open governance is not just fairer – it is more effective at driving standardisation.
The end of the one-platform future
Trade finance has moved beyond the era of waiting for a single global platform to solve everything. The industry has learnt that shared standards work better than monolithic systems.
“We are not going back to the one global platform that solves everything.”
– Przemysław Koper, CEO at Espeo Software
What emerges instead is a pragmatic ecosystem: a network of specialised platforms and services, bound together by standard data formats and APIs, governed by legitimate industry bodies. This ecosystem is more resilient, more flexible, and more innovative than any single platform could be.
For organisations implementing trade finance technology, the implications are clear: invest in standards-based tools, avoid proprietary lock-in, and plan for a future where you will integrate multiple platforms. The organisations that make this shift early will find it easier to scale, adapt, and compete as the industry evolves.
Frequently Asked Questions
The most important standards are the ICC Digital Standards Initiative (ICC DSI) and Key Trade Documents and Data Elements (KTDDE) for document schemas, DCSA standards for electronic bills of lading, and UNCITRAL standards for electronic commerce and payments. These define what data should appear in key trade documents and how systems should exchange them. Major banks and carriers actively participate in maintaining these standards.
True eBL interoperability requires three elements: a standardised data model (such as KTDDE), a standardised format for digital signatures and custody chains (such as DCSA standards), and a standardised transfer mechanism. When these are in place, an eBL issued on one platform can be transferred and accepted on another platform without manual re-entry. Today this is the target architecture, though universal interoperability is still emerging.
A network of networks is an architecture where multiple specialised platforms or services coexist and communicate through standard APIs. For example, one network handles document issuance, another handles compliance validation, and a third handles settlement. Rather than forcing all participants onto one platform, a network of networks allows them to choose tools that fit their business while remaining interoperable.
Key items include: commitment to recognised data standards (ICC DSI, KTDDE, DCSA), published and standard APIs, participation in standards bodies, a public roadmap for standards support, ability to run external validation services, and a clear data export path if you leave the platform. The goal is to avoid vendor lock-in and ensure the platform will remain relevant as standards evolve.
Validation services integrate via standard APIs that accept trade documents in standardised formats (e.g., eBLs in DCSA format). A bank sends a document to the validation service, receives a compliance score or decision, and uses that to automate downstream processes such as payment release. This works only if the validation service supports standard formats and does not require a proprietary connection to a specific document platform.
Without standards, each integration between two platforms is a custom project. A bank connecting to five platforms faces five separate engineering efforts. With standards, vendors can build to a common specification once, and the integration works across all compliant platforms. This lowers per-integration cost and allows smaller banks and carriers to participate without commissioning custom code.
Further Reading
To deepen your understanding of digital trade standards, these resources are authoritative:
- International Chamber of Commerce (ICC) – Trade policy and standard-setting body. Home to the ICC DSI and KTDDE.
- Digital Container Shipping Association (DCSA) – Standards for electronic bills of lading and container data. Published the DCSA standards for eBL interchange.
- UNCITRAL – United Nations Commission on International Trade Law. Develops standards for electronic commerce, cross-border payment, and trade law.
- Bank for International Settlements (BIS) – Central banks’ research and analysis on payment systems, settlement, and financial infrastructure.
- SWIFT – Messaging and settlement network used by thousands of financial institutions. Standards for payment instructions and trade finance messages.
- Espeo Software – Blockchain and trade finance technology consultancy.
This post is based on an episode of On The Block, Espeo Software’s series on blockchain and decentralised technology. Direct quotes have been lightly edited for readability.
