Customs risk targeting & trade-fraud detection (undervaluation, misdeclaration, origin fraud)

Customs authorities cannot inspect more than a small fraction of consignments, so they rely on risk selection. Machine-learning models rank declarations and pre-arrival cargo data by the likelihood of fraud (undervaluation, wrong tariff code, false origin, duty circumvention, low-value parcel abuse) and learn from the results of earlier controls. Used well, this concentrates scarce inspection capacity on the cases that matter and speeds up legitimate trade. In the EU the topic is moving fast: the 2026 customs reform, the end of the EUR 150 duty exemption and the planned EU Customs Data Hub all increase data volumes and the need for automated targeting.

Problem & value

• Who: national customs administrations (in Germany the Zoll), the new EU Customs Authority (EUCA), and, as a compliance mirror image, large importers, customs brokers and forwarders who need to find their own risky declarations and suppliers before an auditor does.
• Today: rule-based profiles and manual selection by officers, partly with national risk rules and EU common risk criteria exchanged via the Customs Risk Management System (CRMS2) [1]. Rules are static, easy to learn around, and generate many fruitless controls.
• Why AI helps: fraud patterns are subtle (price slightly below peer shipments, shifting HS codes, transhipment through a third country) and live in high-dimensional, extremely imbalanced tabular data; fraud labels exist only where an inspection took place, so models must handle label scarcity and selection bias.
• Volume driver: the EU reform entered into force on 21 Sep 2026; the EUR 150 duty exemption for low-value parcels is removed, a temporary EUR 3 duty per item applies from 1 Jul 2026 and a Union handling fee from 1 Nov 2026; non-EU platforms become "importers for distance sales", and the EU Customs Data Hub will gradually become the single interface (mandatory for e-commerce from 1 Jul 2028, for all traders from 1 Mar 2034) [2].
• Evidence (research, not deployment ROI): a study on over 8 million import declarations reports that sharing fraud knowledge across countries could improve detection "up to 2-11 times" [4]; GraphFC, a semi-supervised graph model evaluated on real data of three countries, reports up to 252 % relative recall improvement over the previous state of the art [5]. These are academic benchmarks; production gains depend heavily on data quality and control capacity.

Variants

• Import valuation and tariff fraud (core): undervaluation, misclassification of HS/CN codes, preference and origin fraud, anti-dumping duty evasion by transhipment or relabelling.
• Low-value e-commerce parcels: very high volume, ICS2 and post-July-2026 duty rules; focus on splitting of consignments, undervalued invoices and platform/seller risk.
• Safety and security targeting on pre-arrival data: ICS2 advance cargo information for goods with security or product-safety risk (drugs, weapons precursors, non-compliant products) [3].
• Export and dual-use control: identify possible diversion; links to sanctions screening (ANOM-016).
• Exporter/importer-side compliance monitoring: company-internal screening of its own customs declarations and supplier prices for errors and exposure (Path A/B, no sovereign powers).
• Passenger risk assessment (PNR/API, ETIAS): covered by the PNR Directive and relevant AI Act Annex III rules; documented here only at policy level (see Risks). Not a customer-side use case.
• Post-clearance audit selection: ranking importers for audit; overlaps PRED-028 and ANOM-018.

How it works

1. declaration / ENS (ICS2) / manifest / invoice data
2. ingestion + normalisation (HS codes, units, currency, EORI, ports, routes)
3. enrichment (price references per HS+origin, trade statistics, company registers, vessel data)
4. feature building (price vs. peer distribution, weight/value ratio, code-switch history, route graph)
5. models: supervised ranking (gradient boosting) + anomaly detection + graph models for trader networks
6. risk score + reason codes + selection rules (capacity-aware thresholds, random control share)
7. officer review (document check / scan / physical inspection / audit)
8. control result feedback
9. retraining, drift monitoring

• Supervised core: gradient-boosted trees (XGBoost, LightGBM) on tabular declaration features remain the reference baseline; benchmark code for this exists with a public synthetic dataset of 54,000 declarations with 22 attributes, generated from 24.7 million real declarations [6][7].
• Graph models: declarations, importers, consignees, products and routes form a graph; GNN approaches (such as GraphFC [5]) address label scarcity and collusive networks.
• Text and classification: product descriptions are checked against the declared HS code (embedding similarity, text classifiers); see LANG-031. LLMs help explain alerts and summarise case files, but should not make the risk decision.
• Random control sample: a share of consignments is selected at random so the model keeps getting unbiased labels (otherwise it only learns from what it already flags).
• Human-in-the-loop: officers decide on controls; the model ranks. Every control result is fed back. Under EU law decisions with adverse effects on a person must not rest solely on automated processing in the PNR context [8].

Data preparation

The core data are customs declarations (ATLAS or national systems), ICS2 advance cargo filings, manifests and invoices, tariff and price references (TARIC, trade statistics) and, most valuable, the outcomes of past controls. In an authority these sit in several legacy systems and archives; in a trading company they live in the ERP, the forwarder's portal, mail attachments and scanned invoices.

Typical gaps: inconsistent HS codes and free-text product descriptions, unit and currency errors, duplicate trader records under different EORI or name spellings, control outcomes that are not stored in a structured way, and a bias because only flagged consignments were ever inspected. Access rights are tight (tax and customs secrecy).

Preparation steps: build an extract of declarations with outcomes (see PREP-005), normalise HS codes, units and currencies, deduplicate traders, join price references (PREP-011, PREP-012), define outcome categories such as no finding, duty adjustment or seizure (PREP-019, PREP-020), and keep a random control sample for unbiased labels (PREP-018). Pseudonymise personal data of traders and drivers for development (PREP-022). Tools: Python with pandas, dbt or Spark, PostgreSQL or ClickHouse, OCR for invoices (DOC-014). Plan on 60 to 70 percent of the total effort for data work; see GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

• public (customs authorities): C, because declaration and control data are confidential state data that must stay in sovereign infrastructure, and authorities rarely find a finished product.
• enterprise (importers, forwarders): C, because the screening is tied to your own customs and ERP data and open-source models keep it auditable; A (GTM software) is fine for simple compliance screens.
• developer: C, because the open-source tabular and graph stack plus public synthetic datasets allow reproducible development.

Path A — Buy (off-the-shelf)

• For authorities: large integrators and national IT providers customise targeting platforms; the German customs IT is state-built (ATLAS), so purchases are projects, not products. Procurement is usually tender-based and sovereign hosting is mandatory.
• For companies (compliance side): global trade management / customs software (e.g. SAP GTS, Thomson Reuters ONESOURCE, Descartes, Livingston, Customs Support, Zonos-type tools) and trade-data/risk-intelligence providers (e.g. S&P Panjiva, Sayari, Altana). Check EU hosting and which checks are rules versus ML.
• Choose A when: you are an importer or broker wanting a compliance screen quickly; authorities rarely buy a finished product.

Path B — Build on cloud APIs

• Managed ML platforms in EU regions (Azure ML, Vertex AI, AWS SageMaker, Frankfurt/EU regions) for tabular and graph modelling; Neo4j / Amazon Neptune for trader networks; LLM APIs with EU data residency for case summarisation and document comparison (invoice vs. declaration).
• Customs data is confidential and often classified as sensitive government data; most authorities cannot use public clouds. Path B fits mainly importers and brokers.

Path C — Self-host (open source)

• Stack: Python with scikit-learn, XGBoost/LightGBM, PyOD or similar for anomaly detection, PyTorch Geometric for graph models, PostgreSQL/ClickHouse for declarations, Neo4j or Memgraph for networks, MLflow for model tracking, Kafka/Flink for streaming; text models via sentence-transformers.
• Hardware: the tabular and anomaly workload runs on CPU servers (HW1); GNN training and optional local LLM for explanations benefit from one GPU (HW2).
• Why recommended: data sovereignty, auditability and no vendor access to declarations. Ops effort: a small data-science and MLOps team plus close cooperation with the risk-analysis unit.

Path D — Custom training

Almost always part of the solution: models are trained on the administration's own declarations and control outcomes. Key requirements are years of history with labelled outcomes, handling of label scarcity (semi-supervised, domain adaptation), cross-country knowledge sharing without sharing raw data [4], and synthetic data for development and vendor benchmarks [6].

State of the art (2026)

• Research: semi-supervised and graph-based models and domain adaptation across countries are the prominent directions [4][5]; a public synthetic benchmark dataset (CTGAN-generated) allows comparison without exposing real trade data [6][7].
• Institutions: the WCO supports members with data analytics capacity building (BACUDA) and the Customs Enforcement Network for seizure intelligence [9]; the EU adds EU-level risk analysis through the planned Data Hub and EUCA, with earlier, more targeted checks, including before goods leave for the EU [2].
• What changed 2025-2026: reform adoption (Sep 2026), removal of the low-value exemption, and ICS2 advance data making pre-arrival targeting the default [2][3].
• Limits and failure modes: extreme class imbalance; selection bias (only inspected goods have labels); adaptive adversaries who learn the profiles; concept drift (new routes, tariffs and trade wars change price distributions); poor data quality in free-text descriptions; risk of unfair burden on small traders or specific countries/nationalities if features proxy protected traits; explanation requirements in appeals.

Shared resources & combinations

• Same stack (tabular-ml + anomaly-detection + graph-ml): ANOM-018 (tax fraud and VAT carousel selection), ANOM-020 (procurement collusion and EU-funds fraud), ANOM-002 (AML monitoring, including trade-based money laundering), PRED-028 (risk-based audit and inspection selection) — one feature store and MLOps platform on HW1/HW2 serves all.
• Data inputs: DOC-006 (extracting data from bills of lading and customs documents), DOC-022 (trade finance documents), LANG-031 (HS/CN/TARIC classification) provide structured features and classification checks.
• Entity and risk context: ANOM-016 (sanctions and adverse media for traders and consignees), ANOM-011 (supplier risk).
• Physical inspection: VIS-045 (AI-assisted X-ray and CT screening) closes the loop between score and scan.
• Shared building blocks: graph database, entity-resolution pipeline (EORI, company names), price-reference data lake, case-management workflow.

Effort, cost & KPIs

• Path A (importer-side): weeks; licences and data subscriptions.
• Path B: 2-4 months for a pilot on a subset of flows; cloud costs are modest compared with data work.
• Path C/D (authority): 6-18 months to production incl. data integration, legal assessment, training of officers; main cost is people and data engineering, not GPUs.
• KPIs: hit rate (share of controls finding an irregularity), additional duties collected per control, precision/recall at the inspection capacity, share of compliant traders released without control, clearance time for low-risk consignments, hit-rate on the random control sample (bias check), drift indicators, fairness metrics across trader groups and origins.

People & change

Start with management and the head of the risk-analysis unit, who own the targeting policy and the legal basis. Involve IT security and the data protection officer early: customs data contain trader and personal data, so a DPIA (Art. 35 GDPR) and clear processor contracts (Art. 28) are needed, and in public bodies the legal basis for profiling must be checked. In authorities the staff council (Personalrat, BPersVG or state law) is involved; in companies the works council applies where logged officer or clerk behaviour is measurable (§87(1) no. 6 BetrVG), plus information duties under §90(1) no. 3 and, if needed, an expert under §80(3). Works council: yes.

Measures to support AI literacy (AI Act Art. 4) should cover officers and analysts: how scores arise, what reason codes mean, and the limits of the model. Pick a pilot group in one office or trade lane, run the model in shadow mode first, and compare it with the existing selection. Typical concerns are fear of being second-guessed and of discrimination against trader groups; address them with reason codes, fairness metrics, a random control share and the rule that officers decide and may override. Document overrides as feedback. See GUIDE-005, GUIDE-008 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: classification depends on the use. Pure goods/trade-fraud targeting of companies and consignments is not listed in Annex III (the border-control point concerns risks posed by persons) and is therefore usually not high-risk, but profiling of natural persons (sole traders, travellers, drivers) can fall under Annex III point 6 (law enforcement, if customs act as law-enforcement authority under national law) or point 7 (migration, asylum and border control, e.g. risk assessment of persons entering) [10]. Art. 5(1)(d) prohibits assessing the risk of a person committing a criminal offence based solely on profiling or personality traits; support for human assessment based on objective, verifiable facts remains allowed [11]. Social scoring and biometric categorisation by sensitive traits are not acceptable features. Check the current application dates of the high-risk obligations, which have been the subject of postponement proposals.
• PNR variant: the PNR Directive requires that decisions with adverse effect must not be taken solely on automated processing, forbids processing of sensitive data and limits retention [8]. Details of passenger targeting are intentionally not covered here.
• Customs law: Union Customs Code risk-management provisions, common risk criteria and EU risk information exchange (CRMS2) [1]; national procedural law and right to be heard before adverse customs decisions; confidentiality of trade data.
• GDPR: declarations of sole traders and individuals are personal data; purposes limited to customs supervision; data protection impact assessment; Art. 22 safeguards against solely automated decisions; law-enforcement processing may fall under Directive (EU) 2016/680 instead.
• Mitigations: human decision on every control, reason codes, regular bias audits, random control sample, model documentation and logging, appeals process, no proprietary black-box models without explainability.

Getting started

1. Inventory data: declarations, ICS2 filings, control outcomes (with consistent labels), price references.
2. Build a baseline gradient-boosting model on the public synthetic customs dataset [6][7] to set up the pipeline and metrics before touching real data.
3. Define the legal basis and AI Act classification (persons versus goods) and run a DPIA.
4. Pilot on one flow (e.g. low-value e-commerce parcels or one commodity group) with a fixed random control share and a side-by-side comparison with existing profiles.
5. Add feedback loops, drift monitoring and fairness reports before scaling.

Sources

1. European Commission, Customs risk management (CRMF, CRMS2, common risk criteria, ICS2) — https://taxation-customs.ec.europa.eu/customs/customs-risk-management_en
2. European Commission, EU Customs Reform (EUCA, Data Hub, timeline, e-commerce duty and handling fee) — https://taxation-customs.ec.europa.eu/customs/eu-customs-reform_en
3. European Commission, customs risk management page referring to ICS2 as advance cargo information system — https://taxation-customs.ec.europa.eu/customs/customs-risk-management_en
4. Park, Kim, Cha — Knowledge Sharing via Domain Adaptation in Customs Fraud Detection (arXiv 2201.06759) — https://arxiv.org/abs/2201.06759
5. Singh et al. — GraphFC: Customs Fraud Detection with Label Scarcity (arXiv 2305.11377) — https://arxiv.org/abs/2305.11377
6. Jeong et al. — Customs Import Declaration Datasets (arXiv 2208.02484) — https://arxiv.org/abs/2208.02484
7. Customs Import Declaration Datasets repository (MIT) — https://github.com/Seondong/Customs-Declaration-Datasets
8. Directive (EU) 2016/681 (PNR Directive) — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016L0681
9. World Customs Organization, Customs Enforcement Network and data analytics (BACUDA) — https://www.wcoomd.org/en/topics/enforcement-and-compliance/instruments-and-tools/cen-suite/cen.aspx
10. AI Act Annex III (points 6 and 7) — https://artificialintelligenceact.eu/annex/3/
11. AI Act Article 5 (prohibited practices, 5(1)(d)) — https://artificialintelligenceact.eu/article/5/