EIH: one ISO 20022 hub between your core banking system and every payment infrastructure.
EIH (Exos ISO HUB) connects the bank's information system to payment infrastructures: instant payments, real-time gross settlement (RTGS), the SWIFT network. The core banking system keeps sending in its own formats; EIH checks, generates the ISO 20022 messages, exchanges them with the scheme, tracks every operation through to settlement and keeps the evidence. Each infrastructure is a module: the hub adapts to the payment rails of any country.
- ISO 20022
- pacs, pain, camt and admi, generated and validated against their schema
- 3 rails
- Instant payments, RTGS and SWIFT MT ↔ MX
- 5 connectors
- REST, JMS, Kafka, SOAP and files to the core banking system
- 1 to 4 s
- From the sending core banking system to confirmed debit, measured on the demo instance
- Every payment infrastructure has its own format, protocol, deadlines and security requirements: certificates, signatures, technical acknowledgements.
- The core banking system speaks its own formats and does not hold all the data ISO 20022 requires.
- A lost, duplicated or unanswered message becomes a financial incident, and the bank must be able to prove what happened.
- Operations teams have no single view of flows, exceptions and settlement positions.
The core banking system should not have to learn every rail: that is the job of the hub.
A back office to follow every transfer, from entry to settlement.
Operators find every transfer, its ISO 20022 messages and the evidence for each step. Supervisors monitor the service, handle exceptions and read the workflow of each rail.
Screenshots taken on a test instance with two fictitious banks (998 and 999) connected to a scheme simulator, using synthetic data. Interface available in French and English.
From core banking to the scheme, in four steps.
Receive
The order arrives from core banking or the channels through an API, a message queue or a file, without changing the source system.
Check
Checks, the bank's own rules and fund reservation with core banking, before anything is sent.
Send and track
The ISO 20022 message is generated, validated, published to the scheme, then tracked until its response: acknowledgements, statuses, deadlines.
Settle and prove
Debit or credit confirmed to core banking, positions reconciled with the scheme, evidence kept for every step.
The full cycle of an ISO 20022 payment, in a single hub.
Several rails, one hub
- Instant payments, RTGS and SWIFT MT ↔ MX.
- Each rail is a versioned module, with its own protocol and state machine.
- A new rail is added without touching the core of the hub.
Core banking integration
- REST, JMS (IBM MQ, ActiveMQ Artemis), Kafka, SOAP and file connectors.
- Reservation, debit and credit driven by the hub, with controlled retries.
- A Java development kit for the bank's own connectors.
ISO 20022 messages
- Generation and parsing of pacs, pain, camt and admi.
- Schema validation before every send.
- Enrichment (UETR, structured data) and a SHA-256 fingerprint for every message.
No message lost or duplicated
- Every exchange is first recorded in the database, then sent: nothing is lost between two systems.
- Received messages are deduplicated and processed in order.
- A publication without acknowledgement is detected, then cleared by four-eyes resolution.
Workflow and rules
- State machine published in the back office, transition by transition.
- The bank's rules are configurable at defined points, without changing the protocol.
- Scheme deadlines tracked by timers, with automatic retries and investigations.
Exceptions and approvals
- Queue prioritised by severity, handling queue and deadline.
- Sensitive actions subject to four-eyes approval.
- Every action requires evidence: scheme message, core banking response.
Supervision
- Live status of the scheme gateway, the hub and core banking.
- Sent and received throughput, p50, p95 and p99 latencies.
- Metrics and traces exported in OpenTelemetry format.
Treasury and settlement
- Positions per session and reconciliation with scheme reports.
- Sessions, cut-off times and historised scheme reference data.
- For RTGS: queue, priorities and liquidity management.
Security and traceability
- OpenID Connect single sign-on and separate roles: operator, supervisor, treasurer, auditor.
- Names and accounts masked; every reveal requires a reason and is logged.
- Audit log of every access and every action.
One module per infrastructure, for the payment rails of any country.
EIH is not tied to one scheme: each infrastructure is carried by a module that knows its protocol, messages, deadlines and security. The rails below are available and validated on simulators; a new rail is built from a supplied template, without changing the core.
- Instant payments (for example GSIMT's instant transfer in Morocco): pacs.008 and pacs.002, cancellations, returns and investigations, scheme timers and reference data.
- RTGS (for example Bank Al-Maghrib's SRBM): pacs.009 and pacs.010, queue and priorities, camt.050 and camt.051 liquidity, camt.053 and camt.054 statements, XAdES-BES signature and certificate-secured REST transport.
- SWIFT: MT ↔ MX conversion (MT101, MT103 and MT202 to pain.001, pacs.008 and pacs.009, and back), handling the loss of information from MX to MT.
- Other infrastructures (clearing, bulk transfers, cross-border payments): a rail template and a development kit to add them.
Proven before it is connected to the scheme.
The hub is built, tested and demonstrated without depending on scheme access. The live connection comes at the end, once everything else is already proven.
Lab
- Simulated scheme and core banking, shipped with the hub.
- Faults, latency and rejections triggered on demand.
- Two-bank demonstration on your own journeys.
Qualification campaign
- Scheme scenarios replayed automatically on every delivery.
- Receiving, sending, cancellations, returns, disaster recovery.
- Evidence archived for every scenario.
Production
- Certification with the scheme operator.
- One instance per bank, highly available.
- Operations manual and incident procedures supplied.
- Banks joining an ISO 20022 payment infrastructure: instant payments, RTGS, clearing.
- Banks migrating their SWIFT flows to MX messages.
- IT departments: one hub instead of one integration per infrastructure.
- Operations, treasury and compliance departments: follow every payment and prove it.
Built for banking environments.
- Mode
- One instance per bank, installed in its own infrastructure (on premises or private cloud)
- Delivery
- Container images, Docker Compose or Helm chart (Kubernetes)
- High availability
- Redundant gateways with automatic failover, disaster reconstruction under four-eyes control
- Databases
- PostgreSQL, Oracle, MySQL
- Messaging
- No internal broker: message queues only at the edges (scheme, core banking)
- Security
- OpenID Connect, separate roles, four-eyes approval, mutual TLS and XML signatures to the scheme
- Operations
- OpenTelemetry monitoring, incident procedures, operations manual
- Languages
- Back office in French and English, labels managed in the database
- Stack
- Java 21 (LTS) · Spring Boot · React
It complements your core banking system, it does not replace it.
EIH does not hold accounts and is not where transfers are entered: they originate in the bank's core banking system or channels. Network access to the scheme (link, certificates) is still provided by its operator. EIH sits between the two to translate, check, route and prove.