Перейти до змісту

ShipCore — Phase 2 EU Compliance Integrations (Deep Technical Specs)

Цей документ деталізує 7 треків EU compliance, які впливають на архітектуру backend/shipcore/compliance/ (рішення C-eFTI-byDesign, decisions-2026-05-12.md). На відміну від phase1 efti-compliance-deep-dive.md (огляд того що існує), цей файл — технічні специфікації для архітектора, який буде писати код у Phase 4 і Phase 8.

Phase 4 (foundation): схеми, projections, signing primitives — execution UA-only. Phase 8 (v1.5 EU expansion): живі connectors, gate-handshake, certified party.

Невпевнені/непідтверджені факти марковані як (?).

Контекст C-eFTI-byDesign

З decisions-2026-05-12.md § C-eFTI-byDesign:

EU multimodal e-document framework
│
├── eFTI (Reg 2020/1056) — road / rail / IWT / air (НЕ sea!)
│       ├── road sub-domain → eCMR (UNECE Protocol 2008, UA ratified 2020-07-13)
│       ├── rail sub-domain → CIM/SMGS digital (ORFEUS, OSJD)
│       ├── inland waterway → CESNI (RIS / ERINOT)
│       └── air → IATA ONE Record (mandatory transition з 2026-01-01)
│
└── EMSWe (Reg 2019/1239) — SEA окремо від eFTI
        └── DCSA eBL TransportDocument

Архітектурний принцип: один canonical shipcore.Waybill → 3 projections (to_efti_road(), to_ecmr(), to_ettn()); sea рухається через окремий path (to_emswe(), to_dcsa_ebl()); compliance/ — cross-cutting sub-package, не Django app.

Track 1 — eFTI Connectors (Regulation EU 2020/1056)

1.1. Регуляторна стек-діаграма

Acta Що встановлює Дата Status
Reg (EU) 2020/1056 Базовий eFTI Regulation 2020-07-15 force з 2024-08-21
Delegated Reg (EU) 2024/2024 eFTI common data set + sub-domain subsets 2024-07-26 у силі
Implementing Reg (EU) 2024/1942 Спільні процедури доступу/обробки даних 2024-07-05 у силі
Implementing Act (gov-systems) Тех специфікації IT-інфраструктури + eFTI Gates 2024-12-20 у силі
Implementing Reg (EU) 2025/2243 (?) eDelivery use в eFTI (друга реалізація) 2025 референс з eDelivery community

Mandatory date for public authorities acceptance: 2027-07-09. Це не date for operator obligation — operators починають voluntary з 2026-01 і поступово ramp до 2029.

Sources: EUR-Lex Delegated 2024/2024, EUR-Lex Implementing 2024/1942, EC eFTI page.

1.2. eFTI Common Data Set — алгебра підмножин

З Delegated Reg 2024/2024 Article-структура:

eFTI common data set (Annex I, верхня абстракція)
       │
       ├─── eFTI road sub-domain   ⊃ {common ∪ road-specific} ← mapping до eCMR
       ├─── eFTI rail sub-domain   ⊃ {common ∪ rail-specific} ← mapping до CIM/SMGS
       ├─── eFTI IWT sub-domain    ⊃ {common ∪ IWT-specific}  ← mapping до ERINOT/CESNI
       └─── eFTI air sub-domain    ⊃ {common ∪ air-specific}  ← mapping до ONE Record

Спільні поля (common data set): - Учасники: consignor, consignee, carrier, freight forwarder (з EORI/VAT/SCAC де релевантно) - Goods description: HS code (≥ 6 digits per ICS2 R3 vs 4 в eFTI baseline), packages, gross/net weight, volume, dangerous goods (UN no., ADR class) - Transport routing: places of loading/unloading, route, transit dates, vehicle/wagon/vessel/aircraft IDs - Document references: linked customs / sanitary / dangerous goods certificates - Signatures: digital signature metadata (X.509 SubjectDN, timestamp, hash algo)

Alignment: elements aligned з трьома моделями — UN/CEFACT MMT-RDM, EU CDM (Customs Code), EMSWe data model. Це дає теоретичну (але не автоматичну) можливість one-data-many-projections.

Practical note: офіційний schema (XSD / JSON-LD context) для eFTI common data set публікується через EC TAXUD / DG MOVE репозиторії (?) — у відкритому GitHub станом на 2025-Q4 повна XSD не знайдена. eFTI4EU reference implementation (release 0.5, февраль 2025) використовує власну схему на базі MMT-RDM + extension layer.

Source: eFTI4EU Reference Implementation 0.5, UN/CEFACT MMT-RDM standards.

1.3. eFTI Gates + eDelivery архітектура

┌───────────────────────────────┐         ┌───────────────────────────────┐
│  Operator IT system           │         │  Competent authority IT       │
│  (e.g. ShipCore)              │         │  (national customs / road     │
│                               │         │   inspectorate)                │
│  ┌─────────────────────┐      │         │      ┌──────────────────────┐ │
│  │  certified eFTI     │      │         │      │  national eFTI gate  │ │
│  │  platform           │◄────────────────────►│  AS4 access point   │ │
│  │  AS4 access point   │      │ eDelivery   │  (Domibus etc.)      │ │
│  └─────────────────────┘      │ (AS4 2.0)   └──────────────────────┘ │
└───────────────────────────────┘         └───────────────────────────────┘

Технологія: eDelivery AS4 2.0 (підтверджена maturity на interoperability event 2026-02-27). Reference open-source implementation — Domibus (CEF eDelivery building block).

Що це для ShipCore: - Phase 4 — НЕ потрібен AS4 (поки UA-only). - Phase 8 — потрібен AS4 access point + certificate from a Member State conformity assessment body. - Option A (heavy): self-host Domibus → отримати сертифікацію → стати certified eFTI platform. - Option B (light): партнерство з вже-сертифікованим eFTI provider (Awery, AEB, Descartes — варіанти dependant на pilot готовності).

Recommendation: Option B у Phase 8, з опціональним downgrade до Option A якщо partner pricing виходить >$50K/year. Phase 9+ розглянути власну certification.

Source: eDelivery AS4 2.0 maturity, eFTI eDelivery ecosystem.

1.4. Road sub-domain

Mapping eCMR ↔ eFTI Data Set:

eCMR field (UNECE Protocol Annex 2008) eFTI road data element Notes
Box 1 Sender consignor name, address, EORI/VAT
Box 2 Consignee consignee name, address, EORI/VAT
Box 3 Place of delivery place_of_unloading + ISO 3166-2 region
Box 4 Place + date of taking over place_of_loading, loading_date UTC offset
Box 6-12 Goods goods_item[*] HS code 6-digit, packaging, marks, gross weight, volume
Box 13 Sender's instructions consignor_instructions free text
Box 15 COD value cod_amount currency ISO 4217
Box 16 Carrier carrier + SCAC if international
Box 17 Successive carrier successive_carrier[*] для multi-leg road
Box 18 Carrier's reservations carrier_reservations free text
Box 22-24 Signatures signatures[*] XAdES B-LTA (long-term archive)

Reference implementations: - UN/CEFACT — semantic Reference Data Model (MMT-RDM), Business Requirements Specification (BRS), XSD schemas. Каноном для UNECE eCMR Protocol 2008. - FEDeRATED — reference architecture для federated data sharing (живі Living Labs 2020-2024). Deliverables: Master Plan + Reference Architecture (Annex Apr 2024). Архітектурні рішення передані до eFTI4EU. - eFTI4EU — 8 пілотів (Austria, Estonia, Finland, France, Germany, Italy, Lithuania, Portugal). Release 0.5 reference implementation Feb 2025. Pilot focus = cross-border road + IWT.

Sources: FEDeRATED eCMR + eFTI, eFTI4EU pilots, UN/CEFACT eCMR development.

1.5. Rail sub-domain

  • Document baseline: CIM (Western Europe + UA з 2022) / SMGS (CIS) / CIM/SMGS hybrid consignment note (CIT-Rail published edition 2025-12-12).
  • eFTI rail data set: subset of common data set + rail-specific (wagon series, train number, marshalling station, UIC route codes per leaflet 920-5).
  • Existing systems: ORFEUS (Western Europe data exchange), УЗ Cargo Online (UA), DBcargo platform (DE), Rail Cargo Group (AT).
  • Status quo: EDIFACT-based exchange domінує. Eurasian Economic Commission Data Model (EAEU) — конкуруюча схема, не aligned з MMT-RDM. eRail Freight ініціативи UIC існують, але production-grade migration на UN/CEFACT моделі — 2026-2028 roadmap, не "live today".
  • CIT (Comité International des Transports Ferroviaires) оновлює CIM consignment note + manual під NCTS-P5 + eFTI у 2024-Q4 / 2025-Q1.

ShipCore implication: для Phase 8 rail integration — fallback до EDIFACT/IFTMIN parser + UI mapping, не "pure eFTI rail" (того ще немає production-wise).

Source: CIT-Rail CIM/SMGS Manual 2025-12-12, CIT-Rail digital freight news.

1.6. Inland waterway (IWT) sub-domain

  • Backbone: River Information Services (RIS) — Directive 2005/44/EC + revision 2024 (?).
  • Standards body: CESNI (Comité Européen pour l'Élaboration de Standards dans le domaine de la Navigation Intérieure) — joint CCNR + EC committee.
  • Existing message format: ERINOT (Electronic Reporting Inland Navigation Object Type) — EDIFACT-based, exchanged on Rhine + Mosel, partial cross-border coverage. CESNI ES-RIS standard is the maintained semantic model.
  • eFTI IWT data set: subset of common + IWT-specific (vessel ENI number, voyage number, draft, cargo loaded/unloaded per port, ADN dangerous goods class).
  • Surprise: IWT — найбільш зрілий sub-domain з точки зору cross-border digital reporting (ERINOT works for years). Не slowest sub-domain.
  • 2025-2027 CESNI work programme — продовжує harmonisation ES-RIS з eFTI semantics.

ShipCore implication: для Phase 8 IWT — leverage ERINOT-to-eFTI mapper (опен-сорсу не знайшов, але можливо CESNI Living Labs publish reference у 2026-2027).

Source: CESNI work programme 2025-2027, CESNI RIS.

1.7. Air sub-domain

  • Document baseline: AWB (Air Waybill) — IATA Resolution 600a.
  • Legacy formats: Cargo-IMP (1975, maintenance stopped 2015) + Cargo-XML (2010, sunset target 2026-01-01).
  • New standard: IATA ONE Record — REST API + RDF/JSON-LD data model. Designated preferred standard з 2026-01-01. Airlines representing 72% of global AWB volumes already on track for adoption.
  • eFTI air data set: subset of common + air-specific (AWB number 3-letter prefix + 8-digit serial, ULD references, flight number, dimensions per piece, special handling codes).
  • Mapping eFTI air ↔ ONE Record: ONE Record's LogisticsObjects data model уже aligned з MMT-RDM semantics на high level. ShipCore strategy — generate ONE Record payload as primary projection, derive eFTI air subset on demand.

ShipCore Phase 9 + Awery partnership (C2 correction) — Awery вже ONE Record lead на IATA WCS 2026; ШС не білдить awia з нуля, інтегрується через Awery API.

Source: IATA ONE Record fact sheet, ONE Record GitHub, Cargo-XML standards.

Track 2 — EMSWe (Regulation EU 2019/1239, SEA-only)

2.1. Регуляторна стек-діаграма

Acta Що встановлює Дата Status
Reg (EU) 2019/1239 EMSWe Regulation, replaces Directive 2010/65/EU 2019-06-20 applicable з 2025-08-15
Delegated Reg (EU) 2023/205 EMSWe data set 2023-02-03 у силі
Implementing Reg (EU) 2023/204 Technical specifications EMSWe 2023-02-03 у силі
Implementing Reg (EU) 2023/2790 Functional/technical specs MNSW Reporting Interface Module 2023 у силі

2.2. Архітектура EMSWe

   Ship/Agent ─── REST/XML ───►  Maritime National Single Window (MNSW)
                                       │
                                       ├──► Customs (CIS, NCTS, ICS2)
                                       ├──► Border control
                                       ├──► Port authority
                                       └──► EMSA central system (SafeSeaNet)
  • Decentralised network — кожна Member State має свій MNSW, EMSA + EC + Commission building blocks провідні.
  • Submission protocols: REST API (modern), XML (legacy). Member State може mandate один чи обидва.
  • Reporting Interface Module (RIM): common entry point для submission (RIM acts as AS4 access point per eDelivery building block — secondary path).

2.3. Member state implementation status

Станом на Q4 2025 (значно нижчий compliance ніж планували — більшість MS не встигли до 2025-08-15 deadline):

MS Status Approach
NL Live Portbase consolidated + national MNSW
PL Live (limited) PUESC integration
DE Live NMSW Germany
IT Live PMIS + national MNSW (Italian Coast Guard governance)
RO Late Constanța primary port, partial coverage Q1 2026 (?)
GR Partial Piraeus MS deferral until late 2026 (?)

Sources: EC EMSWe page, Italian Coast Guard EMSWe, Venturn EMSWe timeline.

2.4. DCSA eBL integration з EMSWe

Important: eBL ≠ EMSWe. DCSA eBL замінює paper Bill of Lading (cargo contract document), EMSWe = port-call formality reporting (ship-side). Перетин: - В EMSWe ship submission можна вказати reference до eBL (transport document number) як evidence cargo manifest matches. - Pre-arrival cargo declarations (ENS — це ICS2 domain, не EMSWe) можуть link до eBL data set.

ShipCore implication для Phase 8: - shipcore_sea pipeline: Booking → eBL (DCSA via hub) → ENS (ICS2) → EMSWe port-call submission. Три окремі connectors, спільний data context. - Не маємо direct EMSWe адаптерів у v1.5 — таргет v2 (Phase 9+) для NL + PL (де UA-маршрути найбільш активні з deep-sea Constanța feeder + Gdańsk).

Track 3 — ICS2 Release 3 (EU pre-arrival ENS)

3.1. Базові факти

  • Legal basis: Regulation (EU) 2015/2447 (UCC IA) + EUCDM.
  • Purpose: pre-arrival risk assessment.
  • Coverage: ICS2 R1 (air express), R2 (air general + postal), R3 (sea + IWT + road + rail) — finalna release.
  • Timing requirements:
  • Sea: ENS at 4 hrs before arrival (short routes) / 24 hrs before loading (deep-sea).
  • Air: house-level ENS for express + non-express.
  • Road: 1 hour before vehicle arrives at first EU customs office.
  • Rail: 2 hours before train arrives at first EU customs office.

3.2. Mandatory dates 2025-2026

Period Status
2025-04-01 ICS2 R3 ENS extended to rail + road
2025-09-01 ICS2 fully operational across all MS (limited derogations)
2025-12-31 Cut-off for MS still accepting ICS1 / NCTS-P5 fallback
2026-06-01 HR, LV, PL, RO, SK mandatory ICS2 (final cut-off MS group)

Source: Taxation Customs transition ICS2 R3 complete, Customs-Declarations.UK ICS2 June 2026.

3.3. Message types per mode

Mode Primary message House-level Notes
Air ENS House Filing ✓ + Air Cargo Manifest (carrier-level)
Sea ENS Sea ✓ for FF/EU importer + DCSA Bills of Lading reference
Road ENS Road ☓ (carrier-only) 1 hr pre-arrival, 6-digit HS mandatory
Rail ENS Rail ☓ 2 hrs pre-arrival

Key data requirements (R3): - HS code: 6 digits mandatory (vs 4 in some legacy systems). Кожен goods item. - EORI of consignor, consignee, declarant — valid format, registered in EU. - Detailed goods description (not just HS — actual text description). - House-level filings require carrier ↔ FF/EU-importer exchange of EORI + transport contract number to link partial ENS filings.

3.4. Connection methods (EOS architecture)

Economic Operator ──┬── STP (Shared Trader Portal)        ← web UI, low-volume, manual
                    │
                    ├── STI (Shared Trader Interface)     ← AS4 + XML, direct connect
                    │   └── via UUM&DS (Unified User Mgmt
                    │        & Digital Signatures)
                    │
                    └── ITSP (IT Service Provider)        ← broker access via AS4

Authentication requirements: - UUM&DS registration для sender, з EORI mapped до digital certificate. - X.509 certificate для sealing messages (integrity + non-repudiation). - AS4 access point конфігурація (Domibus self-host чи vendor managed).

3.5. Architecture decision для ShipCore

Phase 8 (v1.5 EU expansion):

Option Pros Cons Recommendation
Direct connect via STI Повний контроль, no per-msg fee Heavy: UUM&DS reg, AS4 ops, X.509 mgmt, ENS XML schemas Phase 9+ якщо volume > 50K ENS/year
ITSP partnership (Descartes, AEB, customs broker) Quick to market, no certification burden Per-msg fee €0.5-2.0 (?), vendor lock-in Recommended Phase 8
Hybrid Direct for high-volume corridors, ITSP for spot Складність — два code paths Phase 9+ розглянути

Phase 4 deliverable: ENS data builder як shipcore.compliance/exporters/ens.py (XML payload generator) + provider-agnostic interface EnsSubmitter з двома реалізаціями (DirectStiSubmitter, ItspSubmitter). У Phase 4 — fixture-based testing only, не live submissions.

Source: EC ICS2 main page, ICS2 FAQ.

Track 4 — eCMR Providers Comparison

Goal: обрати платформу для ShipCore-Auto + ShipCore-Forwarder UA→EU road shipments (Phase 8). Опції: TransFollow / DigiCMR / IRU eCMR-EPD / Open Logistics Foundation self-host / build.

4.1. Open Logistics Foundation eCMR (OLF) — open-source primary candidate

  • License: Apache 2.0
  • GitLab: git.openlogisticsfoundation.org/wg-electronictransportdocuments/ecmr
  • Components:
  • ecmr-backend — backend (235 commits станом на check, 33 branches; created 2024-03-07).
  • ecmr-frontend — UI.
  • ecmr-model — data model.
  • ecmr-token-manager — auth/role management.
  • Editions:
  • Full version — для logistics service providers які піднімають свій eCMR з нуля.
  • Core version — для тих хто вже має eCMR і хоче use OLF interface for interop.
  • Status: "production-ready" представлено на transport logistic 2025 (Munich, June 2025).
  • Backed by: Fraunhofer IML + dogado (host) + Open Logistics Foundation working group "Electronic Transport Documents".

Self-host requirements (inferred): - Java/Spring Boot backend (typical Fraunhofer/Open Logistics Foundation pattern — потрібно verify в repo) (?). - Postgres database (?). - Docker-compose / Helm artifacts presence — потрібно verify (?). - Custom CA / OIDC for sign-in.

Pricing: €0 license. Cost = infra + integration + support.

ShipCore architectural fit: - ✅ Apache 2.0 = можна embed або deploy aside ShipCore. - ⚠️ Java stack ≠ ShipCore Django — варіант: окремий sidecar service з REST API bridge. - ✅ Аktivний community, EU-orientation, multilingual. - ⚠️ Production maturity — short track record (live <12 months), мало documented customer pilots станом на mid-2025.

Source: openlogisticsfoundation.org/ecmr, GitLab repository, trans.info article.

4.2. TransFollow

  • Founded: by FENEX (NL freight forwarders association) + TLN (NL transport employers), 2016.
  • Coverage: NL primary, FR, ES (mandatory eCMR consideration 2026), Benelux pilot до July 2027.
  • Pricing structure: subscription tiers (no public price list); historical claim €2000-€6000/month для mid-size carriers (?) — не verified у publicly available 2025 sources. На marketplace logistics.cloud "TransFollow e-CMR Start" доступний pay-per-document.
  • API: TransFollow Connect API — TMS/ERP/WMS integration. Documentation gated за account.
  • Market share: домінує NL + significant FR.
  • Strengths: mature, broad shipper acceptance, mobile drivers app.
  • Weaknesses: opaque pricing, closed ecosystem (не open source), vendor lock-in.

Source: transfollow.org, TransFollow Spain mandatory news.

4.3. DigiCMR

  • Origins: Belgium-Luxembourg, Benelux eCMR pilot since 2017.
  • Coverage: Benelux focus, expanding to FR/DE.
  • Pricing: opaque; historical reports per-document fee €1-3 (?).
  • API: REST API, documented for partners.
  • Market position: smaller than TransFollow, fokused на cross-border BE-NL-LU corridor.

Source: TransFollow eCMR market overview (DigiCMR mentioned historically).

4.4. IRU eCMR-EPD

  • Origins: IRU (International Road Transport Organisation) — same body that manages TIR carnet system.
  • Coverage: designed for IRU member national associations (AsMAP-UA, BAG-DE, etc).
  • Pricing: не publicly listed; included with IRU TIR / membership benefits (?).
  • Status: конкурує з commercial providers; уповільнений rollout.
  • API: не well-documented externally.

Note: "IRU eCMR-EPD" не плутати з TIR-EPD (electronic pre-declaration для TIR carnet — separate, mature product).

Source: IRU CMR page.

4.5. Build (own implementation)

  • Pros: повний контроль, no per-doc fee, native ShipCore integration.
  • Cons: UN/CEFACT eCMR XSD support + XAdES signing + UI for driver mobile + IG P&I insurance acceptance = ~4-6 months effort. Без endorsements (IG P&I, FIATA), comercial рекіпіюти не приймуть.

Verdict: don't build from scratch. Use OLF as base, не reinvent.

4.6. Recommendation

Phase 8 strategy: hybrid OLF + TransFollow

ShipCore-Auto (UA-only) → eCMR via OLF self-hosted ← Phase 4-5 PoC, Phase 8 hardened
                          └─ для UA-внутрішніх + UA→Constanța road shipments

ShipCore-Forwarder (UA→EU)
   ├─ Shippers що accept OLF → OLF
   └─ Shippers що mandate TransFollow → TransFollow API integration

Why hybrid: 1. OLF як default — open, no per-doc fee, fits ShipCore open-core narrative. 2. TransFollow connector — survival у NL/FR/ES markets де shippers вимагають саме TransFollow. 3. Architecture у shipcore.compliance/exporters/ecmr.py — provider-agnostic builder, multiple EcmrSubmitter impl (OlfSubmitter / TransFollowSubmitter / DigiCmrSubmitter заглушка).

Phase 4 deliverable: canonical Waybill projection + OLF SDK exploration (1 spike day). Phase 8 deliverable: OLF production deployment + TransFollow account onboarding (тільки якщо pilot ZAMMLER подтвердить попит).

Track 5 — eBL Interoperability Hubs (Deep Comparison)

5.1. Context

  • 9 carriers committed 100% eBL до 2030 (MSC, Maersk, CMA CGM, Hapag-Lloyd, ONE, Evergreen, Yang Ming, HMM, ZIM).
  • DCSA Interoperability Framework (May 2025): PINT API + Legal Framework + Control Tracking Registry (CTR).
  • First production interoperable transaction: 2025-05-15 — CargoX ↔ EdoxOnline, HMM carrier, Suzano shipper.
  • DCSA eBL API v3.0 — IQAX first to go live on GSBN, 2025-06-11.

5.2. CargoX

  • URL: https://cargox.io
  • Tech: blockchain (Ethereum-based BAT — Blockchain Document Transaction Protocol).
  • License/legal: P&I IG approved.
  • API: REST, documented for ERP integration.
  • Carrier coverage: MSC, Maersk, Hapag-Lloyd, ONE, ZIM, HMM, CMA CGM partial. FIATA eFBL issuance support for FF members.
  • Pricing: 1 CargoX unit = $1 USD. Per-transfer pricing з volume discounts. FREE HMM eBL issuance + transfer until 2026-12-31 (promo).
  • Production maturity: ✅ live production with HMM 2025-05-15 (first DCSA-interop transaction).
  • Strengths: FIATA eFBL support (важливо для FFs), price transparency.
  • Weaknesses: не всі major carriers однаково активні.

Source: CargoX platform, CargoX HMM pricing, Interop production article.

5.3. WaveBL

  • URL: https://wavebl.com
  • Tech: blockchain (private network, Hyperledger or similar).
  • Carrier coverage: MSC, ZIM, Hapag-Lloyd, ONE, PIL. Largest eBL issuer "in over 100 countries".
  • API: standalone web app + API for legacy integration + SWIFT connectivity (for banks).
  • Pricing: "No Upfront Costs" + "Pay-as-You-Go" tiered subscription. Trial = 2 eBLs / 45 days. Не publicly listed unit price.
  • Production maturity: ✅ mature, оператор з 2017-2018. MSC primary partnership.
  • Strengths: MSC + ZIM + Hapag-Lloyd combined = most major liners. SWIFT proof-of-value with 5 global banks 2024-10.
  • Weaknesses: opaque pricing, не FIATA-focused.

Source: WaveBL platform, WaveBL pricing, WaveBL SWIFT POV.

5.4. Enigio (trace:original)

  • URL: https://enigio.com
  • Tech: NOT blockchain — "trace:original" data-centric approach, document file is self-contained.
  • Legal status: IG P&I approved (April 2024+).
  • Carrier coverage: carrier-agnostic; FFs + carriers issue independently. Compatible w/ ICC DSI, FIATA eFBL, BIMCO eBL, DCSA B/L.
  • API: REST.
  • Pricing: "Pay once, use forever" — pay for issuance, free transfer to any party regardless of subscription. Subscription tier для issuance volume (?) — no public price list.
  • Production maturity: ✅ live, integrated з TradeGo for Europe-China route (2025).
  • Strengths: best interoperability — free transfer to non-subscribers — unlocks adoption barrier. Standards-agnostic.
  • Weaknesses: менш активний з deep-sea major carriers (focus = FF + bank tranactions).

Source: enigio.com, IG P&I approval, Enigio Europe-China channel.

5.5. TradeGo

  • URL: https://tradego.com (китайський origin, Singapore HQ).
  • Tech: blockchain.
  • Carrier coverage: focus Asia-Europe trade; partnered з Enigio for Europe-China DCSA-compliant transactions. WaveBL + TradeGo joint interop with ONE + large FF preparing (announced 2025-05).
  • API: REST.
  • Pricing: не publicly disclosed.
  • Production maturity: ✅ live Asia-EU.

ShipCore relevance: secondary candidate — covers Asia rail/sea routes (MarketCorridor "Asia rail" first-class entity per D10). Phase 9+ priority.

Source: Smart Maritime Network DCSA interop article.

5.6. IQAX / GSBN

  • URL: https://iqax.com (IQAX) + https://gsbn.global (GSBN network)
  • Tech: GSBN = blockchain-based network з spoke carriers; IQAX = solution provider that issues eBLs on GSBN rails.
  • Carrier coverage: COSCO, OOCL, Hapag-Lloyd, ONE, COSCO Specialized, COSCO Ports. Hapag-Lloyd reached 100% eBL via IQAX on GSBN.
  • API: DCSA eBL API v3.0 live since 2025-06-11. PINT API support implied.
  • Pricing: IQAX публічна заява "no additional cost to customers" — likely embedded в carrier eBL fee. GSBN — network-level (carriers pay).
  • Production maturity: ✅ most production-mature DCSA-compliant implementation. 550,000+ eBLs processed via GSBN.
  • Strengths: best DCSA technical compliance, Hapag-Lloyd reference (UA-EU relevant).
  • Weaknesses: China-centric ownership (COSCO + GSBN consortium) — geopolitical considerations.

Source: IQAX DCSA v3.0 launch, Hapag-Lloyd 100% eBL via IQAX.

5.7. Comparison summary

Hub Tech UA-key carriers covered DCSA API v3.0 Pricing transparency Recommended for ShipCore
CargoX Blockchain (Ethereum) MSC, Maersk, Hapag-Lloyd, ONE, ZIM, HMM ✅ (PINT) High ($1/unit) ✅ Primary (FIATA eFBL + UA market)
WaveBL Blockchain (private) MSC ★, ZIM, Hapag-Lloyd, ONE, PIL Partial Low ✅ Secondary (MSC mandates WaveBL)
Enigio trace:original (file-based) Carrier-agnostic, FF-friendly ✅ Medium ("pay-once") ✅ Niche (cross-platform transfers, banks)
TradeGo Blockchain Asia-focused Partial Low ⏳ Phase 9+ (Asia rail corridor)
IQAX/GSBN Blockchain (GSBN) COSCO, OOCL, Hapag-Lloyd, ONE ✅ First v3.0 Low (carrier-embedded) ⏳ Phase 9+ (Asia + Hapag-Lloyd)

5.8. ShipCore Phase 8 strategy

Multi-hub adapter pattern в shipcore.compliance/exporters/emswe.py + shipcore.sea.exporters/ebl.py:

class EblPlatformAdapter(Protocol):
    def issue(self, dcsa_ebl_payload: dict, carrier: Carrier) -> EblHandle: ...
    def transfer(self, handle: EblHandle, to_party: Party) -> None: ...
    def surrender(self, handle: EblHandle) -> None: ...

# Concrete:
CargoXAdapter, WaveBlAdapter, EnigioAdapter, IqaxAdapter

Routing logic: Based on Carrier.preferred_ebl_platform (FK seeded at carrier onboarding). Falls back до user-chosen primary per Tenant settings.

Initial scope: Phase 8 v1.5 — CargoX + WaveBL (covers ~80% of UA-EU deep-sea volume with MSC + Maersk + Hapag-Lloyd). Enigio + IQAX — Phase 9+.

Track 6 — T1 / NCTS Phase 5 + UA Customs

6.1. NCTS-P5 status

  • Live з 2025-01-21 — all 36 Common Transit Convention countries on Phase 5 (including UA since April 2024 + final stragglers AD, BE, HU, MT, PT, SM live 2025-01-21).
  • Ukraine: перейшла на NCTS-P5 у квітні 2024 (одна з перших 6); готується до NCTS-P6 із завершенням project у 2026 (EU PFM Support Programme).
  • Phase 6 transition (EU MS): scheduled June 2025 (?) — partial migration.

6.2. Architecture (common domain)

Economic Operator ───┬─── Trader Portal (web UI, manual)
                     │
                     ├─── Brokerage software (commercial)
                     │     └─ commercial: AEB, Descartes, Customs4trade, Conex,
                     │        x7trade, національні solutions (UA: QDPro, M.E.Doc)
                     │
                     └─── Direct connect (API per national customs)
                           └─ via UUM&DS authentication

Three-level message exchange: 1. External domain: EO ↔ national customs. 2. National domain: customs offices ↔ within MS. 3. Common domain: national customs ↔ EC TAXUD ↔ other MS.

6.3. Key changes vs P4

  • Data model: based on EUCDM (EU Customs Data Model) v6.x.
  • Mandatory EORI: в transit declaration (or full name+address; не obox).
  • Guarantee amount declaration: principal має задекларувати exact reserved amount.
  • Authorised Consignor/Consignee codes: linked до EORI + guarantee.
  • EORI validation: strict format rules; declarations rejected if invalid (effective 2025-11-26 per DDNTA 5.15 v2.0.0).
  • House-level declarations are now mandatory for transit (vs P4 master-only).

6.4. ShipCore options (UA-internal + UA→EU transit)

Option A: Bridge через M.E.Doc / SOTA - M.E.Doc — domінуючий e-document service в UA, integration з PTAH document mgmt + FlyDoc + SOTA web service. - M.E.Doc підтримує NCTS submission через своїх brokerage modules (verified indirectly; no public API docs for ShipCore-to-MeDoc connector). - ⚠️ No documented REST API for third-party software integration. Existing integrations leverage X.509 cert exchange + EDI/XML file drop.

Option B: Bridge через QDPro - QDPro / INTES — Ukrainian customs software since 1993, has NCTS support per ITC association membership. - Like M.E.Doc — primarily file-drop / X.509-based, no public REST API for third-party.

Option C: Direct connect (Trader Portal API replacement) - UA customs Trader Portal буде phased out per NCTS-P5 doctrine ("system will interact with companies through brokerage software"). - ⚠️ Direct connect для UA-side declarations потребує UA customs authorisation; ResolutionUUM&DS analog в UA — Дія BankID + EORI-UA — under development for 2025-2026 (?).

Option D: Foreign principal / EU broker - Якщо UA cargo транзитує через EU → принципал declarations подаються EU broker з EORI у EU MS. - ShipCore-Forwarder integrates з EU broker via Descartes / AEB / Customs4trade API.

6.5. Recommendation

Phase 4 (UA-only v1): No NCTS integration in ShipCore code. Лишити це у external software (clients use M.E.Doc / QDPro отдельно). ShipCore-Forwarder Booking lifecycle has hook on_transit_required що emit event для external broker workflow.

Phase 8 (v1.5 UA→EU): Option D — EU broker bridge. - Primary: AEB (German vendor, mature NCTS integration, strong UA-DE corridor coverage). - Secondary: Descartes (broader scope, US-headquartered, expensive but feature-rich). - ShipCore connector pattern: shipcore.compliance/exporters/ncts.py — transit declaration data builder (EUCDM-format XML) + NctsBrokerAdapter (AebAdapter / DescartesAdapter).

Phase 9+: spike on direct connect через UA→EU customs visa-free flow if Дія EORI-UA fully live + UA tax authority publishes REST API for NCTS submission. M.E.Doc bridge тільки якщо це з'явиться як supported integration.

Sources: EC NCTS Phase 5 page, NCTS-P5 Ukraine first 20 countries, Ukraine NCTS-P6 dev.

Track 7 — Sign-twice Strategy (UA→EU cross-border)

7.1. The interoperability gap

UA-side signing standard: - ДСТУ 4145-2002 (Ukrainian elliptic curve digital signature standard). - Based on short Weierstrass curves distinct from NIST P-256/P-384 — not bit-compatible. - Implementations: Дія КЕП (qualified cloud signature), Almaz-1K, Krystal-1, Secure Token hardware tokens. - Signature format: typically PKCS#7 / CAdES variant, less commonly XAdES-with-DSTU-extension.

EU-side signing standard: - eIDAS-compliant QES (Qualified Electronic Signature). - Crypto curves: NIST P-256, P-384, P-521; RSA-2048+; brainpoolP256r1+. - Signature format: XAdES для XML payloads (B-B, B-LT, B-LTA tiers), CAdES для binary, PAdES для PDF. - DSTU 4145 ECC NOT in eIDAS approved curve list (verified per eIDAS Cryptographic Requirements v1.4.1 — minimum 250-bit, P-256+ required).

Consequence: UA-side QES (Дія КЕП) технічно валідний у UA + юридично визнається в EU (per eIDAS Article 14 — third-country trust services з reciprocity), але не вкладається у XAdES стандартний XML signature flow.

Source: eIDAS Cryptographic Requirements v1.4.1, eIDAS interoperability paper.

7.2. signxml Python library — production readiness

  • GitHub: XML-Security/signxml
  • License: Apache 2.0
  • Implementations: W3C XML Signature Standard v1.1 (required components + most recommended).
  • XAdES support: dedicated signxml.xades module — XAdESSigner, XAdESVerifier.
  • Crypto backend: uses cryptography (pyca) + lxml. Resists common XML attacks (XXE, signature wrapping, transform abuse) — secure defaults (no network calls, no XSLT/XPath).
  • Signature tiers supported: B-B (basic), B-LT (long-term — adds CertificateValues + RevocationValues), B-LTA (B-LT + ArchiveTimestamp).
  • References per signature: by default 3 (data + KeyInfo + signed properties).
  • PyPI: pypi.org/project/signxml — actively maintained.

Production verdict: ✅ ready for ShipCore.

Caveat: signxml uses pyca cryptography — curves limited to those supported by OpenSSL (NIST + brainpool + Curve25519). No DSTU 4145. Confirmed via PyPi project metadata.

Source: signxml GitHub, signxml docs, signxml PyPI.

7.3. Дія КЕП integration

  • Service: ca.diia.gov.ua (Qualified Trust Service Provider operated by State Enterprise "DIIA").
  • Integration portal: integration.diia.gov.ua/signature.
  • Two flows:
  • Дія.Підпис (mobile app) — мобільний QES для individuals via Дія app + 5-digit PIN + photo. Cloud-based.
  • File-based КЕП — locally-stored keys на Almaz-1K, Krystal-1, Secure Token, USB flash. Local signing libraries.
  • API patterns:
  • Server-side (file-based): ShipCore backend calls UA crypto provider library (Український "Бібліотека криптографії" — proprietary distribution) → produces DSTU 4145 signature → embed у CAdES envelope.
  • Client-side (Дія.Підпис): ShipCore generates document → presents до user → user signs via Дія app → ShipCore receives signed blob.
  • Documentation: Ukrainian-only, limited public API specs (potentially closed для public — частково accessible via partner agreement).

Existing precedent в ESWF: backend/medoc_bridge/ (✅ existing, partial) — M.E.Doc файлове X.509 ETTN signing flow. Patterns reusable.

Source: Дія КЕП integration, Дія validation, Дія КЕП main.

7.4. Sign-twice architecture

Use case: UA exporter ships goods to EU consignee via UA→PL→DE road. Need: 1. UA-side legal validity — eTTN signed with Дія КЕП (DSTU 4145 + CAdES). 2. EU-side legal validity — eCMR signed with eIDAS QES (XAdES B-LTA via signxml + EU CA-issued cert).

Architecture decision: dual signature on canonical Waybill.

shipcore.compliance/signing/
├── kep_dia.py        ← DSTU 4145 signer wrapper (calls UA crypto lib subprocess
│                       or via partner SDK; or client-side flow with Дія.Підпис)
├── xades.py          ← signxml.xades XAdESSigner wrapper, B-LTA tier
└── sign_twice.py     ← orchestrator: canonical Waybill →
                          (a) generate ETTN projection → sign w/ kep_dia → store
                          (b) generate eCMR projection → sign w/ xades → store
                          (c) audit log entry

Practical signing flows:

Document Signer (legal) Signature format Key custody Trigger
eTTN (UA national) Driver, dispatcher DSTU 4145 / CAdES Дія cloud or USB token Mobile app onPosted
eCMR (international) Sender, carrier, consignee XAdES B-LTA EU QES (CA-issued) OnTransfer event
EORI consignor signature on ENS Customs declarant CAdES via UUM&DS UUM&DS digital cert Pre-arrival timer

Audit logging: shipcore.compliance/audit.py — для кожної signing operation: who / what document / which signature format / certificate fingerprint / timestamp / TSA timestamp token. Required для legal disputes + future eIDAS audit.

7.5. Cross-border bridge — open questions

  • Trust list interop: UA є на EUTL whitelist (?) — частково; Ukrainian QTSPs визнаються EU per Ukraine-EU association agreement, але technical bridge cert chain не automatic.
  • DSTU 4145 → XAdES bridge: некомерційно існує (?), partners like Agrello (Estonian e-sig vendor) — implemented Diia support for cross-border workflows.
  • Phase 8 deliverable: spike on Agrello-style bridge vs double-signing approach. Double-signing більш resistant до bridge failures.

Source: Agrello Diia integration article.

7.6. Recommendation

Phase 4 foundation: 1. Implement signxml.xades.XAdESSigner wrapper (shipcore.compliance/signing/xades.py) — works for synthetic EU QES test certificates immediately. 2. Skeleton shipcore.compliance/signing/kep_dia.py — interface only; реальна implementation чекає Дія КЕП partner agreement / SDK access. 3. sign_twice.py orchestrator skeleton з dual-projection signing pipeline. 4. audit.py — повний логер з day 1.

Phase 8 hardening: 1. Дія КЕП real integration — server-side через UA crypto lib або Дія.Підпис client-side flow. 2. EU CA certificate provisioning — partnership з UA-friendly QTSP (e.g. Cesidian RootCA-like or commercial: Notakey, eSignly, Cryptomathic). 3. EUTL trust list cache — periodic sync для XAdES verification path.

Summary & Architecture Recommendations

S.1. Architectural foundation (Phase 4)

backend/shipcore/compliance/
├── __init__.py
├── audit.py                          ← single source of truth for compliance log
├── exporters/
│   ├── __init__.py
│   ├── canonical.py                  ← canonical Waybill abstract
│   ├── efti_road.py                  ← Waybill → eFTI road sub-domain XML/JSON-LD
│   ├── efti_rail.py
│   ├── efti_iwt.py
│   ├── efti_air.py                   ← + ONE Record RDF projection
│   ├── ecmr.py                       ← Waybill → eCMR (UN/CEFACT) + OLF SDK adapter
│   ├── ettn.py                       ← Waybill → eTTN (existing in shipcore_auto/)
│   ├── emswe.py                      ← Waybill (sea) → EMSWe submission
│   ├── ens.py                        ← Waybill → ICS2 ENS XML
│   └── ncts.py                       ← Waybill (transit) → NCTS-P5 transit decl
├── signing/
│   ├── __init__.py
│   ├── xades.py                      ← signxml.xades wrapper (B-LTA)
│   ├── kep_dia.py                    ← Дія КЕП wrapper (skeleton Phase 4 → real Phase 8)
│   └── sign_twice.py                 ← orchestrator
├── mapping/
│   ├── __init__.py
│   ├── ettn_to_ecmr.py
│   ├── ecmr_to_efti.py
│   └── canonical_waybill.py          ← одна модель → 3+ projections
├── adapters/                          ← external platform connectors
│   ├── __init__.py
│   ├── ecmr/
│   │   ├── olf.py                    ← Open Logistics Foundation client
│   │   ├── transfollow.py            ← TransFollow Connect API
│   │   └── digicmr.py                ← DigiCMR (Phase 9+)
│   ├── ebl/
│   │   ├── cargox.py
│   │   ├── wavebl.py
│   │   ├── enigio.py                 ← Phase 9+
│   │   └── iqax.py                   ← Phase 9+
│   ├── ens/
│   │   ├── descartes.py              ← ITSP for ICS2
│   │   └── aeb.py
│   ├── ncts/
│   │   ├── medoc_bridge.py           ← UA-side, file-drop
│   │   ├── aeb.py                    ← EU-side principal
│   │   └── descartes.py
│   └── efti_gate/
│       └── domibus.py                ← AS4 access point (Phase 9+)
└── tests/

S.2. Phase 4 scope (compliance-by-design foundation, UA execution)

Component Type Effort estimate
canonical.py Waybill abstract model 3 days
exporters/ettn.py refactor з shipcore_auto/ refactor 2 days
exporters/efti_road.py skeleton + fixtures new 4 days
signing/xades.py (signxml wrapper) new 2 days
signing/kep_dia.py skeleton + interface new 1 day
signing/sign_twice.py orchestrator new 2 days
audit.py logger new 1 day
mapping/canonical_waybill.py 3 projections new 5 days
Tests + fixtures (UN/CEFACT samples) tests 4 days
Total Phase 4 compliance/ ~24 days = ~5 weeks

This confirms Phase 4 "+30% effort" estimate з decisions-2026-05-12.md § C-eFTI-byDesign.

S.3. Phase 8 scope (v1.5 EU expansion)

Track Activity Provider primary Estimate
eCMR live OLF self-host deploy + adapter OLF + TransFollow fallback 2 weeks
ICS2 ENS live ITSP partnership + submission Descartes or AEB 3 weeks
eBL live Two-hub adapters CargoX + WaveBL 3 weeks
EMSWe (lite) Single MS pilot (NL or PL) Direct submission 2 weeks
NCTS-P5 EU broker Bridge AEB 2 weeks
eFTI gate certification path Research + partner partner Mid (?) 1 week (research) + ongoing
Sign-twice prod Дія КЕП SDK integration Diia + EU QTSP 3 weeks
Total Phase 8 EU compliance ~16 weeks (4 months)

S.4. Critical dependencies & risks

Risk Impact Mitigation
OLF eCMR production maturity unverified Phase 8 timing Phase 4-5 — embed OLF PoC + benchmark vs TransFollow trial
eFTI Gate certification timeline opaque Phase 8 partner choice Track EC certification body announcements; Phase 8 partner provider, not own gate
Дія КЕП no public REST API Phase 8 sign-twice depth Phase 4 prep partner agreement з Diia / Agrello-style vendor
DCSA PINT API still evolving (v3.0 just live) eBL adapter stability Lock to v3.0 schema; track v3.x patches; CargoX + WaveBL handle PINT internally
NCTS-P6 transition 2026 Phase 8 NCTS adapter rework Use abstracted EUCDM mapping; both adapters target EUCDM not raw P5/P6 messages
ICS2 6-digit HS data quality All UA→EU shipments blocked Item master DB harden — Item.hs_code 6-digit validation Phase 4 hard requirement

S.5. Open questions for Phase 3 (deferred research)

  1. OLF eCMR backend tech stack — Java vs other; Docker artifacts presence; integration patterns for non-JVM clients. Action: spike-day Phase 3.
  2. eFTI Gate certification process detail — який Conformity Assessment Body accept ShipCore; timing для UA-platform certification (since UA не EU MS, потрібен EU-MS partner). Action: outreach DG MOVE.
  3. TransFollow API actual pricing — public marketplace logistics.cloud показує "TransFollow e-CMR Start" pay-per-document — verify pricing models for mid-volume (~100 docs/month).
  4. Дія КЕП commercial SaaS API — partner agreement terms; alternative: Agrello / Notakey reseller для cross-border.
  5. MSC eBL platform preference verified — підтвердити що MSC mandates WaveBL exclusively, чи приймає інші DCSA-compliant hubs.

Sources (consolidated)

Regulations (EUR-Lex)

eFTI ecosystem

ICS2 + NCTS

eBL hubs

eCMR providers

IATA Cargo + ONE Record

Signing + eIDAS

eDelivery

Sanctions screening (для Track 4 sanity check — not deep here)

Phase 2 deep-dive закрито 2026-05-12. Phase 3 (architecture detail design для compliance module + Phase 4 task breakdown) стартує з оновлених припущень.