Transit movements from departure to destination,
in a single flow, by the rules.
NCTS Phase 6 compliant national transit application.
CustomsFlow is the national application of the common transit system (NCTS) for customs administrations. It was built according to the NCTS Phase 6 national transit application design document published by the European Commission: the departure, transit and destination office roles run on their own state machines, every message is validated against defined rules and written to an immutable record, and existing customs systems are connected through an adapter.
NCTS Phase 6 design document568 rules, versioned catalogAdapter to existing systemsLive integration monitor
24On hareket
3Under control
11Transitte
6At destination
1Under enquiry
| MRN | Güzergah | Son mesaj | Status |
|---|---|---|---|
| 26XX00000000001042 | Departure A → Transit B → Destination C | CC029C | Released for transit |
| 26XX00000000001043 | Departure A → Destination D | CC060C | Under control |
| 26XX00000000001038 | Departure E → Transit B → Destination A | CD118C | Arrival accepted |
| 26XX00000000001021 | Departure A → Destination F | CC045C | Movement closed |
| 26XX00000000000997 | Departure C → Destination A | Zamanlayıcı | Enquiry |
DEPARTUREDeparture office AReleased for transit
TRANSITOffice of transit BAwaiting crossing
DESTINATIONOffice of destination CArrival expected
IE015Trader declaration received; schema, code list and rule checks passed09:12CC028CMRN issued, guarantee usage recorded09:12CC060CRisk score above threshold: control decision notified09:13CC029CReleased for transit with officer approval09:41CD050CAdvance notification sent to the office of transit09:41
Operations board · Role-based landing: open movements, statuses and latest messagesCustomsFlow screens · fictitious data
A movement’s journeyVehicle üç kapıdan geçer,
Vehicle üç kapıdan geçer,
the record never breaks.
Vehicle çıkıştan varışa her gümrük kapısından geçerken mesajlar üretilir, garanti kilitlenir ve serbest bırakılır. Hareketin durumu her ofiste aynı kayıttan görünür.
Transit hareketi · 26XX00000000001042Example hareket · kurgusal veri Declaration received
IE015Trader declaration received; it passed schema, code list and rule checks.Guarantee lockedGuarantee releasedBarrier closed
IE015Departure officeThe declaration is received, an MRN is issued and the guarantee is locked; after control, the movement is released for transit.
CD050COffice of transitReceives the advance notification; when the vehicle is presented, it allows the crossing and reports the border crossing.
CD006COffice of destinationAccepts the arrival and reports the control result to the departure office.
CC045CClosureThe movement is closed and the guarantee released; every step stays on record.
ProblemTransit rules are changing,
Transit rules are changing,
systems cannot keep up.
The new phase of the common transit system brings hundreds of message rules, dozens of message types, business timers and two-way messaging with partner country administrations. Building this into existing customs systems takes a long time and requires redevelopment with every rule change.
Rules embedded in code
When rules and code lists live inside the application, every change becomes a software project.
Many external systems
Declaration, risk, guarantee, export and partner administrations; each one means a separate connection and a separate error format.
Invisible message traffic
Seeing which message stalled a movement, and why, means tracing it across more than one system.
How does it work?From declaration to closure
From declaration to closure
in four steps.
Every step from the trader’s declaration to closing the movement follows the message and state definitions in the design document; business timers are kept as data, and a movement whose time runs out automatically moves to enquiry.
- 1
Beyan alınır
The trader’s message passes schema, code list and rule checks; if it passes, an MRN is issued and guarantee usage is recorded; if not, it is rejected with the rule that was breached.
- 2
Risk ve kontrol
If the risk engine’s score is above the threshold, a control decision is notified; the departure officer makes the decision on their own screen.
- 3
Transit and destination
The movement is released for transit; the offices of transit and destination are informed through common domain messages and make their own decisions.
- 4
Closure
The arrival result returns to the departure office, the guarantee is released and the movement is closed. A movement whose time runs out is placed under enquiry.
Ofis rolleri30 states, 18 decisions,
Departure office
Transit ofisi
Office of destination
30 states, 18 decisions,
one movement record.
As a transit movement passes through the departure, transit and destination offices, each office writes its own status and decision to the same record. States and transitions were built from the official diagrams in the design document; what is waiting at which office is visible at all times.
3Office rolesDeparture, transit and destination, each with its own state machine.
30Official statesThe movement’s status at each office, under its name in the design document.
18Decision migrationiDecisions visible only on the authorized officer’s screen.
15Business timersWhen time runs out, the movement automatically moves to enquiry.
15
resmi durumhareketin bu ofisteki halleri
6
karar migrationidecisions the officer can make
The office where the declaration is lodged
Declaration acceptance, risk and guarantee checks, control decision, release for transit, cancellation and enquiry.
KazanımControl decision, guarantee and release for transit on one screen; a rejected declaration returns to the trader with the number of the rule breached.
9
resmi durumhareketin bu ofisteki halleri
7
karar migrationidecisions the officer can make
The office where the border is crossed
Receiving the advance notification, presentation of the vehicle, allowing or refusing the crossing.
BenefitThe advance notification reaches the office before the vehicle arrives; the officer’s crossing decision is reported to the departure office via a common domain message.
6
resmi durumhareketin bu ofisteki halleri
5
karar migrationidecisions the officer can make
The office where the movement ends
Acceptance of arrival, control result, release of the goods and notification to the departure office.
BenefitArrival and control results return to the departure office by message; the movement is closed and the guarantee is released.
Message validationEvery message passes eight gates,
Every message passes eight gates,
invalid ones return with their rule.
Every message from the trader or the common domain is validated in the order set out in the design document. Rules live in a versioned rule catalog, not inside the application code: 568 rules and conditions, and when they change, the catalog is updated, not the code.
IE015Trader declaration · LRN DEMO-0042✓1SchemaXSD structure
✓2Kod listesiOrtak referans veri
✓3SSequence check
✓4BRTMigration dönemi kuralları
✓5CConditionlar
✓6RRules
✓7TTeknik kurallar
✓8GGuidelines
…
Validating messageEight checks run in sequence; validation stops at the first error.
Accepted messageThe movement moves to the next state and a response message is generated; for example, an MRN is issued for the declaration (CC028C).
Rejected messageA rejection message (CC056C) showing which rule was breached returns to the trader; the movement’s state does not change.
Recorded either wayThe message XML and its result are written to the immutable record and shown on the movement card.
IntegrationYour existing systems
✓ Nonebirinde değişiklik yapılmaz
Your existing systems
stay in place.
CustomsFlow connects to the customs administration’s running systems through an adapter layer and requires no changes to them. Eight integration points speak the same contract, and every call is recorded.
Your existing systems
Beyan sistemi
Risk motoru
Guarantee management
Export system
Common domain network
Trader channel
Referans veri
Availability
CustomsFlowON BUTTERFLY
- Transit engine · roles, states, timers
- Rule catalog · 568 rules and conditions
- Immutable record · every message and call
200risk · skor 78 · kontrol
0 changes to existing systems1 call contract, 8 pointsEvery call logged with full request and responseLive monitor: in the screens above
From the fieldFor a national customs administration,
For a national customs administration,
an end-to-end prototype in one day.
An NCTS Phase 6 national transit application was built as a prototype on Butterfly for a national customs administration. All data was fictitious; test scenarios were run end to end via the browser and API.
- 1 dayEnd-to-end kurulumThe entire flow, from departure to transit and from arrival to closing the movement, was built and run in one day.
- 568Rules and conditionsThe design document’s rules and conditions were loaded as a versioned catalog, together with 5,517 code list entries from common reference data.
- 8Integration pointsDeclaration, risk, guarantee, export, common domain, trader channel, reference data and availability; one contract, live monitor.
- 19 / 20Test scenarios passedIncluding guarantee errors, rule violations, crossing refusal, cancellation and enquiry. The remaining one is a deliberately simplified rejection flow.
CapabilitiesFor national transit,
For national transit,
everything you need.
Role-based state machinesSeparate state machines for departure, transit and destination; states carry the official names from the design document.
Versioned rule catalogRules and conditions are read from the catalog, not from code; code lists come from common reference data.
Immutable message recordEvery message is stored with its XML; the message chain and content open from the movement card.
Timers as dataBusiness timers are kept as records; a movement whose time runs out moves to enquiry.
Adapter-based integrationA single call contract; when switching to the real system, only the adapter changes, while the engine and screens stay the same.
Role-based authorizationAdministration, departure, transit and destination officers and the trader; everyone sees only their own screen and decisions.
Which teams is it for?Teams managing transit movements
Teams managing transit movements
end to end.
Customs administration officers
Departure, transit and destination officesWhy? ↻Why?
Tracing a movement across several systems to see why it is waiting slows down decisions.
What it doesSeeing the movement’s status, the message chain and their own decision on one screen.
Departure, transit and destination officesTraders and customs brokers
Beyan sahipleri, lojistik ekipleriWhy? ↻Why?
Rationalesiz bir red, aynı beyanın deneme yanılmayla tekrar gönderilmesine yol açar.
What it doesSeeing why a declaration was rejected, with the rule number, and knowing where the movement is.
Beyan sahipleri, lojistik ekipleriCustoms IT and integration teams
System and integration managementWhy? ↻Why?
If rules live in the code, every phase change means a new software project.
What it doesMonitoring external system calls in real time and putting new rule sets into service without writing code.
System and integration management
Trust and controlExisting systems stay unchanged,
Existing systems stay unchanged,
every step is recorded.
CustomsFlow is designed not to replace the customs administration’s running systems but to connect them to the common transit system. Every message and every external call is recorded; decisions rest with the authorized officer.
Control
- Every message in an immutable record, with its XML
- Every external call recorded with full request and response
- Decisions only on the authorized officer’s screen
- Times stored in UTC, shown in local time
Platform
- Connects to existing customs systems via an adapter
- Starts in Opt-Out mode, ready for Opt-In
- Multilingual interface
- Can be deployed on-premises
Needs assessment
CustomsFlow and your transit process: how good a fit?
8 questions, two minutes. At the end, see CustomsFlow’s fit scorecard for your transit process and the reasons behind it.
- Transit scope
- Rule ve mesaj
- Integration
- Audit
Frequently askedAbout CustomsFlow
About CustomsFlow
about Butterfly.
CustomsFlow nedir?
It is the NCTS Phase 6 national transit application of the common transit system (NCTS) for customs administrations. It brings departure, transit and destination office roles, message validation, business timers and external system integrations together in a single application on the Butterfly platform.
Which document was it built on?
It was built according to the NCTS Phase 6 national transit application design document (DDNTA, version 6.4.1) published by the European Commission. States, transitions and message types follow the official definitions in that document.
Do we need to change our existing customs systems?
No. Beyan, risk, garanti, ihracat ve referans veri sistemlerinize adaptörle bağlanılır. All entegrasyon noktaları aynı sözleşmeyle konuşur; gerçek sisteme migrationte yalnız adaptör değişir.
What happens when the rules change?
Rules and conditions live in a versioned rule catalog, not in the application code. A new rule set is put into service with a catalog update.
Does it support Opt-Out and Opt-In modes?
The application was set up to start in Opt-Out mode and designed to be ready for the switch to Opt-In.
Liveda kullanılıyor mu?
CustomsFlow was built and tested as a prototype with fictitious data for a national customs administration. Going live requires connecting to the administration’s own systems and passing official conformance tests.
Can it be deployed on-premises?
Yes. CustomsFlow runs on the Butterfly platform and can be deployed on the customs administration’s own infrastructure; access is granted through role-based authorization.