Pillar 3 · Implementation

One Integration Full Compliance Zero Legacy Overhaul

The most persistent objection to structured address compliance is the assumption that it requires replacing core payment systems. It does not. The integration effort is identical for hybrid and structured.

The "Sidecar" Architecture

The address resolution engine operates as an adjacent service. It does not replace any component. No modifications to core banking systems, payment engines, or legacy infrastructure.

┌───────────────────────────────────────────────────────────────────┐
│                     EXISTING INFRASTRUCTURE                       │
│                                                                   │
│  ┌──────────┐    ┌───────────────┐    ┌──────────────────┐        │
│  │ Payment  │───▶│  Middleware   │───▶│  Correspondent   │        │
│  │Initiation│    │  (MuleSoft,   │    │  Banking /       │        │
│  │ System   │    │   Volante,    │    │  SWIFT Network   │        │
│  │          │    │   Finastra)   │    │                  │        │
│  └──────────┘    └──────┬────────┘    └──────────────────┘        │
│                         │                                         │
│                    API Call                                       │
│                         │                                         │
│                  ┌──────▼───────┐                                 │
│                  │   ioNova     │                                 │
│                  │   Address    │  ◄── SIDECAR SERVICE            │
│                  │   Resolution │      (No core changes)          │
│                  │   Engine     │                                 │
│                  └──────────────┘                                 │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

Supported Middleware Platforms

MuleSoft Anypoint

Pre-built connector available for Anypoint Exchange.

Volante VolPay

Direct API integration with VolPay message transformation layer.

Finastra Fusion

Integration via FusionFabric.cloud open API framework.

Custom / SWIFT Direct

Standard REST API or Alliance Lite2 and Alliance Access paths.

Implementation: Week by Week

Phase 1 · Weeks 1–4
Analysis & Configuration
Audit data quality, map payment flows, identify integration points, configure country-specific parsing rules, define confidence thresholds, complete integration design.
Phase 2 · Weeks 5–10
Integration & Testing
Implement API connection, build message interception, functional testing across corridors, validate ISO 20022 schema compliance, volume and performance testing.
Phase 3 · Weeks 11–16
Deployment & Go-Live
Staged rollout to production, monitor accuracy, extend to all corridors, optimise rules, complete knowledge transfer and operational handover.

The Automatic Fallback: Zero Payment Disruption

Every resolution attempt produces a confidence score. Above threshold → fully structured output. Below threshold → automatic fallback to hybrid format, populating maximum structured elements. No payment is ever held, delayed, or rejected.

Initial implementations achieve 85–90% full structuring rates, rising to 95%+ within the first quarter of production operation.

Circuit-Breaker Protection
If the resolution service experiences disruption, payments route through the existing flow automatically. Zero downtime risk.

Implementation FAQs

Does implementing address intelligence require replacing core banking systems?

No. This is the most persistent misconception about structured address compliance. The ioNova address resolution engine operates as a sidecar service alongside existing infrastructure—it does not replace any component. No modifications are required to core banking systems, payment engines, or legacy infrastructure. The engine connects via standard API to existing middleware layers (MuleSoft, Volante, Finastra, or direct SWIFT connections) and processes addresses in the message flow without disrupting payment routing.

What is sidecar architecture for payment address resolution?

Sidecar architecture is a deployment pattern where the address resolution engine operates as an adjacent, independent service that intercepts payment messages via API call, resolves and structures the address data, and returns the enriched message—all without modifying the core payment flow. The middleware platform makes an API call to the sidecar service during message processing. If the service is unavailable, payments automatically route through the existing flow via a circuit-breaker mechanism. This means zero downtime risk and no dependency on the resolution engine for payment continuity.

How long does it take to implement ISO 20022 address structuring?

Typical implementation completes in 10–16 weeks across three phases. Phase 1 (weeks 1–4) covers data quality audit, payment flow mapping, integration point identification, and country-specific parsing rule configuration. Phase 2 (weeks 5–10) handles API connection implementation, message interception, functional testing across corridors, and ISO 20022 schema compliance validation. Phase 3 (weeks 11–16) manages staged production rollout, accuracy monitoring, corridor extension, and operational handover. Compare this to 18–36 months for building in-house or 6–18 months for retrofitting postal tools.

What middleware platforms support address intelligence integration?

ioNova provides pre-built integration for the most common payment middleware platforms: MuleSoft Anypoint (via pre-built connector on Anypoint Exchange), Volante VolPay (direct API integration with the message transformation layer), and Finastra Fusion (via the FusionFabric.cloud open API framework). For institutions using other platforms, a standard REST API is available, along with direct SWIFT integration paths via Alliance Lite2 and Alliance Access.

What happens if the address resolution service goes down during payment processing?

No payment is ever held, delayed, or rejected due to the address resolution service. A built-in circuit-breaker mechanism ensures that if the resolution service experiences any disruption, payments automatically route through the existing flow—exactly as they did before integration. Additionally, every resolution attempt produces a confidence score: addresses above the confidence threshold receive fully structured output, while those below the threshold automatically fall back to hybrid format, populating the maximum number of structured elements possible. Initial implementations achieve 85–90% full structuring, rising to 95%+ within the first quarter.