A shared verification layer for transits of the Suez, Panama, Corinth and Kiel canals. The ship’s agent files the papers once, registries and insurers confirm them at source, canal departments decide, and the pilot checks a signed clearance on board.
It does not replace canal, customs, treasury or port systems. It adds a verification and trust layer between them.
Figures from the sandbox platform. Pilot results will be measured with each canal authority and published here.
Concept film · 30 seconds
A short vision of how a transit could work once the canals are connected: papers submitted once, confirmed at source, accepted by Suez, Panama, Corinth and Kiel, and checked by the pilot on board.
Concept film with sample data from the sandbox; the platform is not yet in service with the canal authorities. On-screen text is in English.
Each authority keeps the systems it runs today. The corridor adds what none of them can provide alone: trust between them.
| Capability | Canal and port systems | Maritime Trust Corridor |
|---|---|---|
| Vessel processing and scheduling | Core system of each canal | Uses the canal’s own data |
| Tariffs and toll calculation | Core system, official tables | Reads the official tariff (the demo uses illustrative tables) |
| Payment collection | Canal treasury and banks | Records the treasury’s confirmation |
| Certificate verification | Partial, often by e-mail or phone | Confirmed with the issuer at source |
| Trust between authorities and parties | Bilateral and limited | One shared, signed record |
| Clearance evidence | Inside each system | A signed clearance any authorised party can check |
| Audit trail across participants | Separate in each system | One tamper-evident trail |
| Data residency | Each authority’s own choice | By design: documents stay with each authority; production is hosted in-country |
The table compares roles, not products. No system is connected yet; each connection would be agreed with the system’s owner during a pilot.
Each step is signed by the party responsible for it and written to a ledger shared by the canals. Nobody re-types a document, and nobody has to trust a photocopy.
Vessel by IMO number, arrival date and tonnage. The ship registry confirms the vessel exists and who flags it.
Class and P&I certificates are checked with the society and the club that issued them, against their validity on the arrival date.
Filed before submission, even when there are none, and acknowledged by the canal’s safety department.
Each canal’s departments decide on the same record and can ask the agent questions. At Suez these are Navigation, Technical, Risk & Safety and Revenue.
Proforma invoice, bank transfer or bank guarantee, convoy slot and marine services such as tugs and mooring.
The Digital Transit Clearance carries a signed QR code. It can be held or revoked if anything changes.
Payment, approvals, holds, convoy slot and the vessel’s AIS position, in one scan. Then arrival, boarding, entry and exit are logged.
The platform does not ask anyone to take a document on faith. It asks the issuer.
Eight controls run on every case. The platform enforces each one rather than leaving it to a checklist, and each is tested automatically in the audit pack.
The check digit of the IMO number is validated, then the ship registry confirms the vessel, its flag and its status.
Class and P&I cover are confirmed by the society and the club, valid on the arrival date. A suspended class or lapsed cover blocks submission.
The pilot’s scan checks the vessel’s AIS position, and gaps in AIS reporting are flagged.
Each department decides only its own step, and every department must approve before an invoice is issued.
Funds are confirmed by the canal treasury, never by the payer. Guarantees are checked for balance, validity and currency.
Issued only after confirmed payment and a confirmed slot. A forged or altered QR code fails the check.
Detention, court arrest, sanctions review or safety inspection blocks the transit until the same authority releases it.
Every entry is hash-chained, so any change is detected. Auditors receive an evidence pack with all eight control tests and the signature check.
The steps of a transit stay the same. What changes is who confirms each fact, and how often it has to be typed again.
| Step | Typical today | With the corridor |
|---|---|---|
| Submission | The same papers sent by e-mail or upload to several offices | Filed once and used by every department of the canal |
| Verification | Calls and e-mails to registries, class societies and insurers | Confirmed by the issuer at source, against the arrival date |
| Forged papers | Scans and photocopies that are hard to check | Issuer confirmation and document fingerprints; any change is detected |
| Review | Departments work from separate files and messages | All departments decide on one record, with questions and answers kept on it |
| Payment | Transfers matched to vessels by hand | Payment confirmed by the canal treasury on the record |
| On board | Paper clearance and radio calls to confirm status | One scan of a signed QR code, which also works offline |
| Audit | Evidence collected by hand from several systems | Audit pack on demand, with automated control tests |
“Typical today” describes common manual practice, which differs between canals. Time and cost targets will be agreed with each authority before a pilot and measured against its current process.
Agency software, shipping-line operations, banks and canal systems connect through one API. Access keys are issued by Columbia One for each partner and role.
| Base address | https://maritime-trust-corridor.columbiaone.io |
|---|---|
| Authentication | Authorization: Bearer <key> |
| Platform status | GET /health, no key needed |
| Message types | GET /api/message-types, mapped to port community messages such as IFTDGN, PLTMEM and BERMAN |
| Transit cases | /api/cases with documents, verification, dangerous goods, decisions, payment, convoy booking, services, clearance, pilot memo and holds |
| Clearance check | POST /api/clearances/check with the content of the QR code |
Approved partner systems receive signed webhooks for the events they choose, under a partner agreement.
Detention, court arrest, sanctions review or safety inspection stop a transit until the same authority releases it.
Agents can pay tolls against an electronic guarantee issued by their bank, checked for balance and validity.
This is a sandbox with five test vessels (IMO 9839131, 9512343, 9301237, 9418626 and 9522154). Tariffs, convoy capacity, service prices and vessel size limits are illustrative and will be replaced during the pilot by the official tables of each canal operator: the Suez Canal Authority, the Panama Canal Authority, Corinth Canal S.A. and the German Federal Waterways and Shipping Administration (WSV).
Plain answers to the questions canal authorities, agents and banks ask first.
None yet. Suez, Panama, Corinth and Kiel are modelled in a sandbox with illustrative tariffs and rules. Connection to each authority is proposed and would start with a pilot under an agreement with that authority.
Vessel identity and registry status, class and P&I certificates, dangerous goods notification, slot booking, marine services, proforma invoice, payment and bank guarantee, pilot memo, clearance, holds and transit events. Each canal’s official list will be confirmed during the pilot.
Not yet. In the sandbox they are simulated services that answer through the same API a real issuer would use, so the whole flow can be shown end to end. Agreements with real issuers come next.
Through one API and signed webhooks, mapped to port community messages such as IFTDGN, PLTMEM and BERMAN. It feeds each canal’s existing systems and does not replace them.
Documents stay with each authority in its own jurisdiction. The shared ledger holds only fingerprints and decisions. In production, each authority’s data is hosted in its own country; this site holds sandbox data only.
No pilot has run yet. Targets for time and cost will be agreed with each authority beforehand, measured against today’s process and published here.
Yes, by design. Documents stay in each authority’s own storage; only their fingerprints and the signed decisions are shared, so any participant can check a clearance without seeing the documents behind it. In production each canal signs its own clearances with its own key; in this sandbox one test key signs for all four canals.
Yes. The interactive demo runs the real platform with test vessels in all four canals and seven languages. For partner API keys, write to us.