IP & Products
Orchestration
SuperStream
Settlement
Nexus CrossStream
Execution
Industries
Licensing & Trust
Company & Insights
Get in touch →
ORCHESTRATION PLANE

SuperStream

The orchestration plane.

SuperStream sits above the acquiring and switching layer. It routes transactions across acquirers, processors, and banks under rules the institution owns, and reconciles what happens back to one operational view of the flow.

Get in touch → See the architecture
ORCHESTRATION
SuperStream
Routing · policy · reconciliation
DOWNSTREAM
Acquirers
and processors
DOWNSTREAM
Switches
and card networks
DOWNSTREAM
Banks
and settlement
ONE CONTROL PLANE · ROUTING · POLICY · RECONCILIATION 5,000+ TPS

The layer institutions use to operate payment flows.

SuperStream is where an institution decides how payments flow. It sits above the acquiring, switching, and issuing layer, applies the institution's routing rules to every transaction, and gives one operational view of what happens across every downstream system.

It runs on top of existing infrastructure or alongside other MonTechSys planes. Either way, this is the layer institutional teams work from day to day.

SuperStream payments operations centre

Four capabilities institutions activate first.

01

Payment routing

Route transactions across acquirers, processors, and rails on rules the institution defines. Cost, latency, success rate, and regulatory constraint are all part of the same routing logic, adjustable and observable at runtime.

02

Real-time reconciliation

Reconciliation happens as transactions do, not overnight in a batch job. Institutions see one operational view of state across every downstream system.

03

Orchestration policy

Route decisions, fallback logic, retry behaviour, and exception handling are written as declarative policy. Teams change them without redeploying. Every change is logged.

04

Observability

Every routing decision, state transition, and exception surfaces in real time. Institutional teams get the visibility they would otherwise build custom integrations to reach.

SuperStream runs inside the substrate, not on top of it.

SuperStream lives on the platform's shared substrate. Every routing decision, downstream call, and reconciliation event lands in the same event model that every other MonTechSys plane uses. That is where SuperStream separates from typical orchestration overlays.

Overlays stitch external systems together with adapters and rely on hope for the reconciliation to hold up. SuperStream routes and reconciles inside one data model instead.

One operational view of what happens across every downstream system.

ORCHESTRATION PLANE
SuperStream
Routing decision
route.select()
Downstream call
orchestrate.execute()
Reconciliation event
reconcile.write()
SHARED SUBSTRATE ONE EVENT MODEL · ONE IDENTITY MODEL · ONE AUDIT TRAIL
Every SuperStream event lands in the substrate every other plane reads from

Every transaction is an event the institution can read.

For institutions that license execution or settlement planes alongside SuperStream, the coherence is native. Nothing crosses a system boundary. For institutions running SuperStream over their existing infrastructure, the substrate still provides one operational view of what those systems are doing.

SUPERSTREAM · EVENT MODEL LIVE STATE
event payment.received
→ identity.resolve(merchant)
→ policy.evaluate(rules)
→ route.select(acquirer, network)
→ orchestrate.execute()
→ reconcile.write(event)
state routing_decision = deterministic
policy applies_at = "every_transaction"
audit captured = true
POST /v2/orchestration/route · <10ms p99

One control plane replaces three fragmented layers.

Most institutions have built or bought some version of orchestration. Custom middleware. A vendor overlay product. A legacy switch stretched well beyond its original purpose. Each solves part of the problem. None of them gives the institution one operational truth across payment flow.

SuperStream replaces those layers with one architected control plane. Existing systems continue running underneath until the institution chooses to retire them.

REPLACES 01

Custom middleware

Internally-built orchestration layers accumulated over the years, each solving a specific routing or reconciliation problem in isolation.

REPLACES 02

Vendor overlays

Third-party orchestration products that sit on top of existing infrastructure and add a layer without resolving the underlying fragmentation.

REPLACES 03

Overloaded switches

Legacy switching infrastructure stretched to handle orchestration responsibilities it was never designed for.

Three deployment paths.

SuperStream deploys in sovereign, managed, or hybrid model. The choice is driven by the institution's regulatory posture and operational preference.

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.

SuperStream deployment environment
Deployment models →

SuperStream works natively across the rest of the platform.

When an institution runs SuperStream alongside other MonTechSys planes, the coherence extends across them. They share the same event model, identity model, and audit trail. Cross-plane operations happen without the usual integration work.

EXECUTION AcquireFlow SuperStream routes across acquiring instances natively
EXECUTION CardForge Issuing decisions coordinated through the same control plane
SETTLEMENT Nexus Settlement reconstructed from SuperStream's event log
EXECUTION BankCore Core ledger movements reconciled in the same substrate
See the full stack →

Evaluate SuperStream against your current orchestration.

A conversation with us includes SuperStream's engineering lead, walks through the architecture, and covers integration options with your existing stack.

Get in touch →