e-CSD — the electronic Customs Security Declaration, explained

What e-CSD is

The electronic Customs Security Declaration is the structured replacement for the paper-and-PDF security declaration that used to ride alongside air cargo into and out of the EU. It moves the declaration onto the FWB itself — specifically into the OCI (Other Customs Information) block — so that every outbound shipment from an EU origin carries a machine-readable, audit-trailed security statement.

It is not optional. EU departures without correctly populated e-CSD fields fail at the carrier or, worse, pass through and surface as audit findings later. Repeat findings put a handler’s Regulated Agent status at risk.

What changed for handlers

Three things, concretely:

1. You need a Regulated Agent (RA) designator on file per station. This is the identifier the EU customs authority assigned you (or the agent acting on your behalf) when it certified you as a Regulated Agent. It looks like NO/RA3/12345-01 — country code, status code, agent number, sub-identifier.

2. The security declaration is captured at acceptance. When the warehouse accepts the cargo, the operator signs the declaration, asserting the security status. Per ICAO Doc 8973, only SPX (secure for passenger and cargo aircraft) and SHR (secure for cargo aircraft only) are valid e-CSD statuses — you cannot issue an e-CSD for cargo that hasn’t been secured. Operator id, timestamp, and the structured payload land in the audit log.

3. The FWB you emit on departure carries OCI fields. The composer reads the station’s RA designator, the captured declaration, and the route. If the route triggers the EU rule, OCI fields populate; if anything is missing, the FWB doesn’t leave.

What the OCI block actually contains

For an EU-departure FWB, the OCI fields you care about:

The block sits in the OCI segment of the FWB; the carrier’s ops desk parses it on inbound and the customs system on the destination side validates it.

What auditors and carrier ops desks actually check

In rough order of how often they come up:

1. Is there an RA designator at all? Empty OCI block is the most common audit finding.
2. Is the RA designator current and matched to the emitting station? Expired or mismatched designators fail.
3. Is the declaration signed by an operator with appropriate authority? Audit log entry per declaration.
4. Did the security method match the SHC? A DGR shipment marked SPX but with an X-ray-only method raises a flag.
5. Can you replay any one shipment’s declaration trail to the second? Operator, timestamp, IP, request id.

How e-CSD is reflected in ONE Record

Cargo-IMP and Cargo-XML carry e-CSD data inside the OCI (Other Customs, Security and Regulatory Information) grouping — a flexible but loose container that’s hard to parse, validate, and selectively share. ONE Record replaces that approach with a dedicated SecurityDeclaration Logistics Object linked to a Shipment (or Piece) via the securityDeclaration property.

The IATA ONE Record specification is explicit on the design intent: when communicating over ONE Record, eCSD data should be carried in SecurityDeclaration, not in OCI. The OCI dumping-ground pattern is what ONE Record was designed to retire.

The 15 e-CSD boxes mapped to ONE Record

The RegulatedEntity object — used in three places

A single shape (RegulatedEntity) carries Boxes 1, 8, and 14 — issuer, received-from, and acceptor. Each is a separate instance with the same properties: regulatedEntityCategory (RA / KC / AO), regulatedEntityIdentifier, regulatedEntityExpiryDate, and a country derived from owningOrganization.basedAtLocation.countryCode.

What changes when you move from OCI to SecurityDeclaration

Three differences worth knowing when mapping legacy messaging into ONE Record:

• The country is part of the identifier. In OCI the country code rode in a separate field; in ONE Record it belongs inside regulatedEntityIdentifier (e.g. DE/H/02082-01). The RegulatedEntity object also derives country from its owningOrganization.
• Expiry date is a real ISO datetime. Messaging used MM/YY. Convert by snapping to the last day of the month: 05/26 → 2026-05-31T00:00:00Z. The dummy 12/99 value used in messaging should not be carried over — leave regulatedEntityExpiryDate empty.
• Consolidation has no boolean flag. Where the paper CSD has a “consolidation” tick-box, ONE Record conveys it implicitly via Waybill#waybillType = Master. When mapping a ticked CSD, ensure the linked Waybill is created as Master.

Re-tendering and audit history

A consignment frequently changes hands between regulated entities — Known Consignor tenders to Regulated Agent, who tenders to the airline. The ONE Record spec is explicit: do not overwrite a previous declaration. Either patch regulatedEntityAcceptor on the existing SecurityDeclaration to record the custody change, or — if the security status itself changes — create a new SecurityDeclaration and link it to the Shipment. ONE Record’s change-request and audit mechanisms preserve the full trail. This is closer to what regulators actually want than the OCI overwrite-in-place pattern messaging tolerated.

A worked example

A SecurityDeclaration for an EU departure, SPX status, screened by physical search and EDS:

{
  "@context": "https://onerecord.iata.org/ns/cargo#",
  "@type": "SecurityDeclaration",
  "securityStatus": "SPX",
  "issuedOn": "2026-04-25T10:45:00Z",
  "issuedBy": { "@type": "Person", "name": "M. Berg", "employeeId": "EMP-4821" },
  "regulatedEntityIssuer": { "@id": "https://1r.acme-handler.eu/logistics-objects/re-12345" },
  "receivedFrom": { "@id": "https://1r.acme-handler.eu/logistics-objects/re-67890" },
  "screeningMethods": ["PHS", "EDS"],
  "additionalSecurityInformation": "Tamper-evident seal 884421."
}

And the RegulatedEntity referenced as the issuer:

{
  "@context": "https://onerecord.iata.org/ns/cargo#",
  "@type": "RegulatedEntity",
  "regulatedEntityCategory": "RA",
  "regulatedEntityIdentifier": "NO/RA3/12345-01",
  "regulatedEntityExpiryDate": "2027-12-31T00:00:00Z",
  "owningOrganization": {
    "@type": "Organization",
    "name": "Acme Air Cargo Handling AS",
    "basedAtLocation": { "@type": "Location", "countryCode": "NO" }
  }
}

To attach the declaration to a shipment, PATCH the Shipment to add the securityDeclaration property pointing at the new object — full request shape and step-by-step in the IATA spec linked at the bottom.

Where this is going

For the next several years, EU departures will need both: OCI-formatted FWBs for carriers still on Cargo-IMP, and SecurityDeclaration objects on the ONE Record server for partners that consume the modern API. Skidd ships both today. As more parties move to ONE Record, OCI becomes the fallback channel rather than the primary one — and the auditability story (per-property change history, OAuth2-delegated read access, HMAC-signed notifications on every update) gets meaningfully better than what messaging ever offered.

For the canonical specification, see the IATA ONE Record CSD documentation and the SecurityStatus code list. For how Skidd’s ONE Record server works generally, see the ONE Record primer.

How Skidd implements e-CSD

Skidd ships e-CSD in Free — not as a paid module, not as a roadmap item. The pieces:

• RA designators per station. Configured in the Security console; the FWB composer reads them on emission.
• Capture at acceptance / kanban / shipment detail. The warehouse op signs the declaration in the same keyboard flow as the shipment accept. Operator + timestamp + structured payload to the audit log.
• OCI emission on outbound FWB. EU departure guard in the composer; refuses to emit if anything is missing.
• Compliance readiness dashboard. “X of Y stations configured” with the unconfigured ones called out.
• Master gates. Tenant flags ecsd_enabled and outbound_fwb_enabled give you a controlled rollout if you’re onboarding e-CSD station by station.

What still requires human judgement

Skidd handles the data pipeline. It does not replace operator judgement about whether a given shipment’s security status is correct. The screener still has to look at the cargo. The supervisor still has to review the exception queue. The compliance lead still has to investigate the audit findings.

What Skidd does is make sure that once a human has made the call, the data flows correctly to the FWB, the OCI block, the audit log, and the readiness dashboard — and that the carrier’s ops desk doesn’t reject the FWB an hour before cutoff because a field is missing.

Where to read the source

The European Commission’s aviation security regulation (currently EU 2015/1998 with the post-2022 amendments) is the regulatory anchor. IATA Resolution 833a covers the FWB OCI block specification. Both are publicly available; both are dense; neither will give you operational guidance on what to actually do at acceptance — that’s what your Regulated Agent training covers and what Skidd encodes into the workflow.