Enterprise platforms · Banking
ISO 20022 payment hub development
We develop ISO 20022 payment hubs for banks and payment companies: one platform that receives payment instructions from every channel, converts them to a canonical model, validates and enriches them, routes them to the right rail and tracks each payment to its final status. The hub speaks pain, pacs and camt messages, sits next to your core banking and screening systems, and you own the code.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Channel connectors
Inputs from APIs, host-to-host file transfer, corporate portals, message queues and Swift connectivity, each mapped onto the same internal payment model. - 02
Canonical payment model
One internal representation that carries every ISO 20022 element, including structured postal addresses, remittance data and purpose codes, so nothing is lost when a message changes format. - 03
Message mapping
Maps between pain.001, pacs.008, pacs.009, pacs.002, pacs.004 and legacy formats, versioned per market usage guideline and tested with sample files from each counterparty. - 04
Validation and enrichment
Schema and business-rule validation, account and identifier checks, charge and FX enrichment, with clear rejection reasons returned to the originator. - 05
Screening and compliance hooks
Calls to sanctions and transaction-screening services at the right step, with the response stored on the payment and holds released only by an authorised user. - 06
Routing and orchestration
A rules-driven choice of rail and route by currency, amount, corridor and cut-off, with a state machine that tracks every payment from receipt to settlement. - 07
Liquidity, limits and cut-offs
Position and limit checks, queuing for cut-off times and release when funds arrive, so payments are neither sent early nor lost in a queue. - 08
Exceptions and investigations
A repair queue for failed and returned payments, and workflows for payment cancellation requests, investigations and returns using camt.056, camt.029 and pacs.004. - 09
Statements and reporting
camt.052, camt.053 and camt.054 reporting to customers and to the general ledger, with reconciliation of what was sent against what settled.
Reference architecture.
Standards and interfaces
What we design against.
- ISO 20022 message families
- pain for customer initiation, pacs for interbank clearing and settlement, camt for cash management and investigations.
- Market usage guidelines
- Swift CBPR+, domestic clearing systems and RTGS each publish their own subset and rules; the hub holds them as versioned profiles.
- Structured and hybrid postal addresses
- Swift's CBPR+ guidelines require structured or hybrid addresses from November 2026, so the model and mapping carry address fields separately from the start.
- ISO 17442 and ISO 9362
- Legal entity identifiers and business identifier codes held as validated reference data.
- OpenAPI and AsyncAPI
- Contracts for synchronous channel APIs and for events published to downstream systems.
- PCI DSS and data protection
- Controls on card-linked data and personal data in payment messages.
Data model
The core entities.
- Payment
- Canonical content of one instruction: parties, accounts, amount, currency, purpose, remittance and charges.
- Message
- Every inbound and outbound message in its original form, linked to the payment it carried.
- Payment state
- Status history with the step, system and reason, including every hold and release.
- Route and rail profile
- Rail, market usage guideline version, cut-offs, limits and fee rules.
- Exception case
- Reason, queue, owner, repair action, investigation messages and resolution.
- Position and limit
- Balances and limits per account, currency and rail, with reservation and release entries.
- Reference data
- Identifiers, calendars, currencies, charge codes and counterparty settings with effective dates.
When custom development is the right call.
Controls designed in, not added later.
Message integrity
Signed and sealed messages, original payloads archived unaltered, and every transformation recorded so a payment can be reconstructed.Idempotent posting
Unique references and de-duplication so a retry never debits or credits twice.Segregation of duties
Release of held payments, changes to routing rules and manual repairs need separate roles and a second approver where policy requires it.Network and key control
Keys in hardware security modules, segregated network zones for rail connections and monitored endpoints.Resilience
Active-active or tested failover, agreed recovery objectives and replay of in-flight payments after a failure.
From discovery to a system you run.
- 01
Payment inventory
We list every payment type, channel, rail and format the bank handles today, with volumes, cut-offs and the system that owns each flow. - 02
Canonical model and mapping design
The internal model and the mapping to each market usage guideline are agreed, with sample messages from every counterparty. - 03
Build by flow
Flows go live one at a time, usually starting with outbound customer credit transfers, then inbound, then investigations and reporting. - 04
Parallel run and reconciliation
The hub runs beside the existing engine, with every payment and statement reconciled until the results match. - 05
Migrate and operate
Flows migrate rail by rail, with monitoring, support and the addition of new rails and formats afterwards.
Relevant work
Where to see our work.
Common questions.
- Do we need a hub, or can we adapt each payment system for ISO 20022?
- Adapting each system works for one or two flows. Once there are several engines, channels and rails, a hub with one canonical model is cheaper to maintain because each new message format is mapped once.
- Which payment rails can the hub connect to?
- Any rail with a documented interface: Swift, RTGS and domestic clearing systems, instant payment schemes and card or wallet networks. Each rail is a connector and a usage profile, agreed with the scheme or operator.
- How do structured addresses affect the design?
- Address parts are stored as separate fields in the canonical model and mapped to the structured or hybrid format each rail requires. Data that arrives unstructured is parsed and flagged for repair rather than rejected silently.
- Does the hub replace the core banking system?
- No. The core remains the book of record. The hub posts to it and reconciles against it.
- Who owns the code and the data?
- You do. The code, the data and any models stay yours, and the system runs in your own environment.