Multi-Network Messaging Switch

One platform that routes ISO 20022 and SWIFT MT payments across SWIFTNet, domestic clearings, and alternative networks -- with policy-based switching, parallel operation, and a single audit trail.
!
1 April 2027 -- HKMA RTGS Dual Network Channel usage quotas become effective for all CHATS members. Dual ICLNet + SWIFTNet connectivity required from DNC launch (expected end-2026).
SWIFT is no longer the only rail

For decades, the operating assumption for cross-currency and high-value payments was simple: one network, one connection, one queue. SWIFTNet carried it all.

That world is changing fast. Major RTGS operators are moving toward parallel network channels -- the Eurosystem's TARGET2 has long offered access via both SWIFT and SIA-Colt, the Bank of England has stated its RTGS renewal aims at a "message network-agnostic" design, and the HKMA has now gone further by mandating prescriptive usage quotas across two channels (see below). Instant payment schemes such as FedNow, The Clearing House RTP, UK Faster Payments, Australia's NPP and SEPA Instant Credit Transfer already run on their own rails. ISO 20022 is the connective tissue across all of them.

The result: institutions that used to run a single SWIFT pipe now need to operate two, three or more network channels in parallel -- often carrying the same ISO 20022 message standard, addressed to the same counterparties, settling in the same currencies, but going out over different wires under different rulebooks.

Bolting a second connector onto a legacy SWIFT stack creates duplicated archives, fractured audit trails, inconsistent validation, and routing logic spread across scripts. The right answer is a network-agnostic switch at the centre of the payment stack -- one engine that knows how to talk to every network and decides, per message, which one to use.

From single-rail to multi-rail
Prowide Messaging Hub
routes to
SWIFTNet (FIN / InterAct)
Domestic RTGS network
Regional clearing
Future network (n)
One switch, every network
The Messaging Hub abstracts the network layer. Back-office systems hand off a payment; the Hub decides which channel carries it, in which format, under which rulebook.

Network Abstraction

Configure each network as an independent channel -- SWIFTNet, domestic IP networks such as ICLNet or CIPS, instant payment schemes, internal rails. Back-office systems do not need to know which one will be used.

Policy-Based Routing

Visual rule builder routes per message: by amount, currency, BIC, counterparty, value date, business unit, time of day, or any payload field. Rules are configuration, not code.

ISO 20022 Native

Same pacs.008 / pacs.009 / camt.* model across every channel. Apply network-specific usage guidelines (CBPR+, HVPS+, regional variants) on the way out without rewriting the business payload.

Quota Enforcement

Distribute traffic across channels to meet regulator-mandated usage ratios -- monthly volume splits, minimum days per channel, per-CHATS quotas. The Hub keeps running counters and steers routing to stay in band.

Contingency Switching

Calendar-driven "single-channel days" exercise each rail end-to-end. Operator-triggered or automatic failover moves part or all of the traffic to the alternate network within seconds.

Format Translation

The same engine that powers our ISO 20022 migration solution converts MT↔MX on the fly when one network speaks MT and another speaks MX, or when usage guidelines diverge.

Unified Audit & Archive

Every message -- regardless of which network it took -- is stored in a single full-text searchable archive with a single audit trail. Reconcile against any monthly network-operator report from one place.

Unified Validation

Apply the right rulebook per network at the point of routing: CBPR+ for SWIFTNet cross-border, HVPS+ for T2/CHAPS/Fedwire, scheme-specific rules for instant payments. Reject before sending, not after.

Operational Visibility

Real-time dashboards show traffic split, queue depth, and per-network status. Operators see at a glance whether the institution is on-track against monthly quotas and contingency requirements.

The switch in the middle
Back-office systems publish payments to the Hub. The Hub validates, translates if needed, applies routing policy, and delivers over the selected network -- with full audit on the way in and the way out.
Payments back-office
Treasury / FX
Securities
Core banking
Prowide Messaging Hub
Capture Validate Translate (MT ↔ MX) Route (policy engine) Archive & Audit
SWIFTNet
Domestic RTGS rail
Instant scheme
Regional clearing
HKMA RTGS Dual Network Channel
A concrete deadline that turns the multi-network story into a 2027 compliance requirement for every CHATS member.

The mandate

On 20 May 2026 the Hong Kong Monetary Authority issued the Real Time Gross Settlement Dual Network Channel Usage Guideline (Ref B5/12C), conveyed to CHATS members via HKICL Circular 2026/154.

From the DNC service launch (expected end-2026), every Authorised Institution must be able to connect to HKD, USD, EUR and RMB CHATS via ICLNet -- HKICL's proprietary IP network -- in addition to the existing SWIFTNet channel. Both networks operate in parallel.

Each AI must maintain dual connectivity at all times and be able to switch part or all of its RTGS traffic between channels swiftly, without causing material delay or disruption.

What you have to prove monthly (from 1 April 2027)

  • 20%–80% of outgoing Inter-bank Fund Transfers via ICLNet, per CHATS the AI participates in.
  • Receive payments via ICLNet on 5 to 15 working days per month, per CHATS.
  • ≥2 working days/month solely on ICLNet and ≥2 working days/month solely on SWIFTNet for contingency.
  • Reconcile against the monthly HKICL DNC monitoring report.
End-2026
DNC service launch -- transition period begins
31 Mar 2027
Transition period ends
1 Apr 2027
Quotas in paragraphs 3-5 become effective
Each requirement, one configuration
Dual connectivity to ICLNet and SWIFTNet
Configure both as independent network channels in the Hub. Each is monitored, validated, and archived through the same engine.
20%–80% monthly volume per CHATS via ICLNet
Quota-aware routing policy with running counters per currency / CHATS. The Hub auto-steers traffic to stay within the band.
5-15 working days/month receiving via ICLNet
Counterparty & calendar rules signal the network of preference for incoming routing on configured days.
≥2 single-channel contingency days each side
Calendar-driven "ICLNet-only" and "SWIFTNet-only" days exercise each rail end-to-end with full audit evidence.
Swift switching between channels on disruption
Operator-triggered or automatic failover redirects in-flight and pending payments to the alternate channel within seconds.
Reconcile against HKICL monthly DNC report
Single archive with per-network tagging produces the matching dataset out of the box. Differences are flagged for review.
ISO 20022 / format alignment per channel
Built-in MT↔MX translation and CBPR+ / HVPS+ usage guideline enforcement on the egress side of each channel.

From the May 2026 announcement, CHATS members have about seven months to be ready for parallel operation at DNC launch and roughly ten months to be inside the usage quotas. Institutions evaluating their target architecture should look at the network layer first.

Discuss your DNC readiness plan →
Multi-network is the new normal
The HKICL DNC mandate is the most explicit example, but the same architecture applies wherever institutions operate more than one payment rail.

Cross-border + instant

Route low-value, time-sensitive flows to instant schemes (SEPA Instant, FedNow, The Clearing House RTP, UK Faster Payments, NPP) and reserve SWIFTNet for higher-value or non-supported currencies -- per-payment, automatically.

CIPS + SWIFTNet for RMB

CIPS direct participants can choose between CIPS's own messaging and SWIFTNet to reach the system. The Hub lets you split CNY traffic between the two based on counterparty reachability and cost, without changing back-office integration.

Architecture-ready for new mandates

The HKMA RTGS DNC is among the most prescriptive dual-network mandates issued by a major regulator to date. The Hub gives institutions an architecture that is in place when -- or if -- their regulator follows a similar template.

Internal vs. external

Route on-us payments through an internal book-transfer rail and keep external traffic on the regulated networks, with the same workflow and audit on both sides.

Cost-aware routing

Use the cheapest reachable network per corridor at every moment. Policy rules can take pricing tables, value date, and currency into account.

Migration windows

Run new and legacy networks in parallel during cutovers, with a controlled volume ramp on the target network. The Hub keeps a single view across both.

A network strategy, not a connector strategy

One integration, many networks

Back-office systems integrate once with the Hub. New networks become a configuration exercise, not a project.

Regulatory readiness

Quota, contingency and audit requirements are first-class capabilities -- not custom scripts grafted onto a single-rail platform.

Lower operational risk

One archive, one audit trail, one validation engine, one team. Network switches stop being a release event.

Preparing for a multi-network world?
Talk to our team about your target networks, routing rules, and regulatory deadlines.