Builders & Intermediaries · Monetise + own processing

Run two businesses on one engine.

A bank sits on both sides of the mandate: it must keep its own outbound pacs.008 traffic compliant at the network boundary (a PSP obligation), and it can sell address quality to the corporate clients EPC §3.2 forbids it from fixing automatically. ioNova ARS runs both on one engine — an In-Flight correction gate on the wire, and a white-label Address-Quality service for clients — as a sidecar with no core replacement.

every pacs
leaves compliant
corridor
-by-corridor rollout
shadow
mode before enforce
2–4 wks
full estate
We have to make sure every pacs.008 leaves us compliant, corridor by corridor, without touching the core. And our corporate clients keep asking us to fix their files — which the rules say we can’t do silently, but could offer as a service. We want both, on one platform, with shadow mode before we enforce anything.
The problem, in their words
Head of Payments / Correspondent Banking

What You Can Do

In-flight pacs correction
Repair transiting messages at the gate, sub-50ms, straight-through preserved.
Correct · In-Flight
Inbound client gate
Repair client files at your liability boundary — where a cost line becomes a billable service.
Validate→Correct
Hosted client correction
Address-Quality-as-a-Service: clients submit pain/pacs and receive corrected XML.
Process
Render to MT
Down-render structured addresses to MT lines for legacy correspondents without losing the structured record.
Render · In-Flight
Returns & recalls
Detect R-transactions and pass them through untouched (EPC §8.3 do-not-modify).
Validate · exempt

From Sandbox to Live

Span
Corridor live in days → full estate 2–4 wks, shadow-mode first
Shape
Dual track — client service (At-Source) + PSP gate (In-Flight)
Tier entry
Enterprise / Partner
1
Get started
Sandbox live, first resolved address in ~2 days
2
Build
Register channels, test; ioNova tunes ~10,000 representative addresses in parallel
3
Validate
Production validation — channels + integrations exercised together
4
Go live
Swap test keys for live keys — no code change

The sidecar binds each flow to its own Channel Profile (e.g. SCT_OUT, CBPR_OUT, FEDWIRE_OUT), so you enable the gate per corridor, run it in shadow mode first, and expand at your own pace. Your payments engineering wires the gate (Volante VolPay, Finastra FusionFabric, SWIFT Alliance, IBM MQ) while ioNova tunes on ~10,000 representative addresses from real traffic. Scheme upgrades (SR2025 → SR2026 → SR2027) ship as configuration, not redeployment.

Why It Pays Off

every pacs leaves compliant a new service-revenue tier per-exception cost off your P&L shadow mode before enforcement circuit-breaker fallback pre-built bank connectors
Where you start
Enterprise or Partner tier, depending on whether you resell hosted correction to your own clients.

Frequently asked questions

Can a bank correct a payment address in transit?

Yes — for its own outbound legs and inbound repair at its liability boundary; but under EPC §3.2 it must pass counterparty addresses through unchanged, which is why client-side fixes are offered as a service.

Can we enforce corridor by corridor?

Yes — each flow binds to its own Channel Profile, so you enable the gate per corridor and run shadow mode before enforcing.

Does it require a core banking replacement?

No — ioNova ARS deploys as a sidecar with circuit-breaker fallback, via connectors for Volante, Finastra, SWIFT Alliance and IBM MQ.

How does a bank monetise this?

By reselling hosted Address-Quality correction to corporate clients whose data it cannot silently fix.

Are returns and recalls protected?

Yes — R-transactions are detected and passed through untouched per EPC §8.3.

How do scheme upgrades work?

SR2025 → SR2026 → SR2027 ship as configuration, not redeployment, with the regulatory burden carried by ioNova.

Live in weeks — before 14 November 2026.

First sandbox call in minutes, first channel live in days. Early Adopter terms end 31 July 2026.