KabyTech Now Parses All 29 FWB/16 Sections

The IATA Cargo-IMP standard is the backbone of electronic air waybill messaging worldwide. The FWB message type carries all the commercial and operational data needed to move cargo by air. Each of the 29 sections serves a specific purpose, and omitting even one can create downstream problems.

For Thai forwarders specifically, the gap has always been the OCI section. Thai Customs requires specific regulatory identifiers in OCI lines for import declarations, including the Customs broker license number, HS code pre-classification references, and security screening status. If your parser skips OCI, your ops team is manually copying this data from the raw message — or worse, from a printed document — every single time.

The OCI (Other Customs, Security and Regulatory Control Information) section is the catch-all for regulatory data that doesn't fit neatly into other FWB sections. It uses a structured format with country code, information identifier, customs information identifier, and supplementary customs information fields. A single FWB can contain multiple OCI lines, each carrying different regulatory data.

For shipments into Thailand, OCI lines typically carry:

• Security screening status (SPX/SCO) — Whether the shipment was screened under a Regulated Agent regime. Thai Customs and CAAT both require this for risk assessment.
• Customs broker identification — The licensed customs broker number assigned by Thai Customs Department, needed for e-Customs filing.
• Country-specific regulatory codes — Thailand's FDA, ACFS (agricultural standards), and DFT (Department of Foreign Trade) all have identifier codes that appear in OCI for controlled commodities.
• EU/US export control references — For shipments originating from the EU or US, export license numbers and ECCN codes appear as OCI data.
• Known Consignor / Regulated Agent identifiers — ACC3 compliance data for inbound EU flights transiting through Thailand.

Without automated OCI extraction, teams typically spend 5-10 additional minutes per AWB manually locating and transcribing these codes. For a brokerage processing 200+ declarations per day, that adds up to 16-33 hours of manual work every single day.

For reference, here is the complete list of all 29 FWB/16 sections now supported by KabyTech:

IATA Cargo-IMP Edition 31, effective from the IATA CSC/31 winter season 2025/26, introduced several refinements that our parser now handles:

• Extended OCI field lengths — The supplementary customs information field was extended from 35 to 65 characters to accommodate longer regulatory identifiers used by ASEAN customs authorities.
• New SPH codes — Three new special handling codes were added for lithium battery classifications (ELM, ELI, RLM), critical for Thailand's growing electronics export sector.
• Multi-line CSD support — The Customs Security Declaration section now supports multiple screening method entries per shipment leg, reflecting the reality of multi-modal security screening.
• UTF-8 encoding guidance — Edition 31 formally acknowledges non-Latin character sets in shipper/consignee fields, which aligns with our Thai language support capabilities.

Our parser uses a multi-pass extraction approach. The first pass identifies section boundaries using the standard IATA line identifiers. The second pass applies section-specific extraction rules, handling the unique formatting of each section type. The third pass runs cross-validation: checking that RTD totals match PPD/COL summaries, that routing airports are valid IATA codes, and that OCI country codes match the shipment's origin or destination.

For OCI specifically, we maintain a lookup table of country-specific information identifiers so we can label each OCI line with its purpose (security status, customs broker ID, regulatory reference, etc.) rather than just returning raw codes. This means your downstream systems can directly consume the data without needing their own OCI interpretation logic.

Full FWB/16 coverage is available now to all KabyTech API customers on Starter plans and above, at no additional charge. If you are on a legacy plan that was limited to 18 sections, your API responses will automatically include all 29 sections starting today. No code changes required on your end — the new sections appear as additional fields in the JSON response.

If you are evaluating KabyTech for the first time, this is the right moment. No other AWB parsing solution on the Thai market offers validated extraction of all 29 FWB sections, and OCI support alone can save your operations team hours of manual work every day.