Cross-border

International Control Tower

Cross-border trips built from lane and touchpoint masters rather than from per-route static configuration, so a new country pair is master data rather than a development cycle.

Request a Demo →All modules

A domestic trip has an origin, a destination, and a road in between. A cross-border trip has an exit post, an entry post, a customs location that may not be at the border, a set of via-countries that depend on the pair, and a different transit expectation for every segment. Configure that per route and you have a maintenance problem that grows with every lane you win.

The platform models it as master data instead. A Touchpoint Master holds the physical points, including border posts modelled as paired exit and entry touchpoints. A Lane Master holds country-pair recipes with their via-countries and segment transit times. When a trip is created the route is resolved at runtime from those masters. Adding a lane is a master-data change.

International

How a cross-border trip is built

Lane Master — country-pair recipes

Each country pair holds its own recipe, including the via-countries a movement legitimately passes through and the expected transit time per segment. Seeded across GCC lanes and extended as master data, not as code.

Touchpoint Master — borders as pairs

A border is not one place. It is an exit post in one country and an entry post in the next, and the platform models it as exactly that pair, so time spent on each side is attributable to the right country.

Automatic route resolution

The route is resolved when the trip is created, from the vehicle, the consignor address, the consignee address and the shipment type. For international LTL that yields the full checkpoint sequence including hub and border touchpoints. Nobody assembles a route by hand.

Customs as its own touchpoint type

Customs is modelled separately from the border crossing, because the two are frequently not in the same place. Where a border has more than one customs location, the operator chooses which one this trip uses.

Geofences created from the address

Origin and destination geofences are generated automatically from the address, with a latitude-longitude fallback where the address does not resolve cleanly. A new consignee does not need a geofence drawn before the trip can move.

Segment transit time — planned versus actual

Each segment carries its own expected transit time, and actuals come from geofence entry and exit. Where a lane loses its time is a measurable question per segment rather than a total that arrives at the end.

Region-to-touchpoint mapping

Regions map to the touchpoints that serve them, including inbound and outbound customs selection, so route resolution works from the geography an operator already thinks in.

Operator override, held to the model

The resolved route can be overridden where reality demands it. The override is recorded against the trip rather than quietly editing the master, so the master stays trustworthy.

Design decisions worth knowing about

Missing master data blocks the trip

No lane, or no region mapping, and the trip will not create. This is deliberate. A cross-border trip built on guessed master data produces a plausible route and an unusable measurement, which is worse than a refusal.

In-flight trips are immune to master changes

A trip snapshots its route at creation. Correcting a lane tomorrow does not silently rewrite what a vehicle did yesterday, so history stays auditable.

Domestic and cross-border on one tenant

The same tenant runs domestic movement inside a country alongside its cross-border lanes, on the same control tower and the same masters.

A platform capability, not a bespoke build

The masters are tenant-level with a platform seed-and-clone path, and the international behaviour sits behind a feature gate, so domestic customers are unaffected. This was built as product, not as a one-off for a single account.

Cross-border daily register

The LTL and FTL daily register is the operational report for cross-border movement — what crossed, what is held, and where each trip stands against its segment plan.

Where we draw the line

Two honest limits. First, this handles the movement and the measurement, not the paperwork: customs document generation and filing are out of scope, and the platform does not produce clearance documents. Second, there is no border wait-time prediction. Segment transit times and dwell at each touchpoint are measured from geofence events, which tells you what a border actually cost you — it does not forecast the queue. Air and sea movements are out of scope; this is surface cross-border.