IP & Products
Orchestration
SuperStream
Settlement
Nexus CrossStream
Execution
Industries
Licensing & Trust
Company & Insights
Get in touch →
SETTLEMENT PLANE · CROSS-BORDER

CrossStream

Cross-border settlement with simpler reconciliation.

CrossStream extends the Nexus settlement architecture across jurisdictions, currencies, and regulatory regimes. Data residency by region, reporting by regulator, and reconciliation by currency are all architectural properties of the platform, not integration projects the institution has to run alongside it.

Get in touch → See the architecture
JURISDICTION
EU zone
residency: EU
JURISDICTION
US
residency: US
JURISDICTION
India
residency: IN
CROSS-BORDER SETTLEMENT
CrossStream
SINGLE SETTLEMENT PASS
MULTI-JURISDICTION · MULTI-CURRENCY FX · SANCTIONS · RESIDENCY

Cross-border settlement with simpler reconciliation.

Cross-border payments accumulate reconciliation debt at every jurisdictional and currency boundary. Data models, reporting formats, and regulatory frames all differ from one region to the next, and every crossing point becomes a surface where those differences have to be reconciled.

CrossStream is architected so cross-border settlement runs in the same event-reconstruction model as domestic settlement. Jurisdictional and currency boundaries become properties of the events themselves, not fault lines the reconciliation has to bridge.

CrossStream global operations control centre

What cross-border settlement should look like.

01

Multi-jurisdiction native

One architectural model for settlement across jurisdictions. It is not one system stitched into another across borders.

02

Per-region data residency

Data resides where regulation requires. The event log stays coherent across regions while the physical storage respects sovereignty.

03

Multi-currency by design

Currency conversion, FX exposure, and multi-currency reconciliation are all architectural features. They are not per-corridor customisations added later.

04

Per-regulator reporting

Regulatory reporting is generated per jurisdiction from the shared audit trail. There is no separate reporting integration to build for each regulator.

The same event model, extended for jurisdiction.

Settlement across jurisdictions is one settlement, not many. CrossStream reads the same event stream as Nexus, enforces per-region data residency at the substrate level, and settles across every jurisdiction in a single pass.

CrossStream operates on the same substrate as Nexus. The event model, identity model, and audit trail are shared. What CrossStream adds is per-jurisdiction context: regulatory frame, data residency requirement, currency, and reporting format all become properties of the events themselves.

The result is that a cross-border settlement outcome is derivable from the same event log a domestic settlement outcome is derivable from. Auditors, regulators, and the institution's own compliance teams all work from the same source.

EU ZONE
residency: region_locked
US
residency: region_locked
INDIA
residency: region_locked
SINGLE SETTLEMENT PASS settle.execute(single_pass)
SHARED EVENT LOG PER-JD AUDIT · PER-REGULATOR REPORTING
Jurisdictional complexity handled architecturally, not by workarounds

FX, compliance, and residency inside one settlement event.

A cross-border settlement resolves jurisdictions, applies FX at spot, clears multi-jurisdiction compliance, enforces residency, and settles in a single pass. Every step writes a per-jurisdiction audit event.

CROSSSTREAM · EVENT MODEL LIVE STATE
event crossborder.settlement.requested
→ jurisdictions.resolve(participants)
→ fx.resolve(rates, spot)
→ compliance.check(sanctions, multi_jd)
→ residency.enforce(per_region)
→ settle.execute(single_pass)
→ audit.write(event, per_jd)
state residency = "region_locked"
audit jurisdictional = true
neutrality = "by_architecture"
POST /v2/crossborder/settle · 99.999%

For institutions where cross-border is a first-class concern.

CrossStream fits institutions where cross-border settlement is a first-class operational concern, rather than an edge case handled by a separate system.

FITS 01

Banks with multi-jurisdiction operations

Cross-border settlement across the bank's own branches, correspondent relationships, and multi-currency exposure.

FITS 02

Processors with cross-border corridors

Settlement across the processor's own multi-jurisdiction footprint plus scheme settlement.

FITS 03

Marketplaces settling across jurisdictions

Cross-border marketplace settlement without a separate reconciliation layer per corridor.

Three deployment paths.

CrossStream deploys in sovereign, managed, or hybrid model. Hybrid is common for cross-border deployments: sovereign per jurisdiction where required, managed where not.

PATH 01

Sovereign

Institution-hosted, institution-operated. Full ownership of infrastructure and roadmap.

PATH 02

Managed

MonTechSys-hosted, institution-governed. Reduced operational burden with ownership of policy and data preserved.

PATH 03

Hybrid

Selective planes hosted, others deployed in-institution. Chosen per regulatory requirement.

CrossStream multi-jurisdiction deployment
Deployment models →

CrossStream and the rest of the platform.

CrossStream inherits the shared substrate. That is the same event model, identity model, and audit trail every other MonTechSys plane operates on.

SETTLEMENT Nexus Domestic settlement inherits the same event-reconstruction pattern ORCHESTRATION SuperStream Cross-border routing decisions coordinated with cross-border settlement
EXECUTION AcquireFlow Operational events feed the same substrate CrossStream settles from
EXECUTION CardForge Multi-currency issuing coordinated through the same event model
See the full stack →

Evaluate CrossStream against your current cross-border settlement.

A conversation with us includes CrossStream's engineering lead, covers cross-border architecture, jurisdictional deployment options, and integration with existing settlement infrastructure.

Get in touch →