Skip to main content

ImPAI Platform Architecture

is engineered as a distributed, event-driven payment processing platform built entirely on microservices. Its architecture emphasizes scalability, fault isolation, and high-volume, low-latency transaction processing across multiple payment schemes.

The platform decomposes complex payment flows into independently deployable services, each running inside containerized workloads organized by Kubernetes. This ensures consistent operation in high-load environments and allows incremental feature deployment without downtime.

Architecture overview Picture: ImPAI Architecture Layers

Interface Layer (Ingress & Exposure)​

The Interface Layer forms the entry point for all external interactions. It provides tightly versioned, schema-validated interfaces for upstream and downstream systems.

Components

  • REST APIs
    • Synchronously triggered call–response interactions
    • Input validation using schema definitions (ISO 20022, proprietary models)
  • File Interfaces
    • Batch ingestion for legacy systems
    • Supports reconciliation files, camt statements, or bulk uploads
  • Inbound/Outbound Channels
    • Online channel: retail/mobile/ebanking initiation
    • Internal channel: operator UI, manual processing
    • Partner/screening services through HTTP, MQ, or Kafka

Technical Notes

  • Request throttling, rate limiting, and client authentication are enforced at the API gateway.
  • All inbound messages are normalized and enriched with metadata before being handed off to the Orchestration Layer.

Service Orchestration Layer (Control Plane)​

The Orchestration Layer implements the processing lifecycle logic. Its tasks are:

  • Stateful routing of transactions
  • Triggering downstream processors
  • Sequencing and branching
  • Scheme-specific process logic (e.g., pacs.008 vs. pacs.004 vs. camt.029)

How it Works
Orchestrators subscribe to events (Kafka/MQ topics) or receive synchronous input from the Interface Layer. Each orchestrator:

  1. Evaluates message metadata
    (e.g., scheme code, business function, lifecycle state)
  2. Selects the required processor
    using a dynamic routing table
  3. Initiates the next workflow step
    (validation, transformation, enrichment, execution)
  4. Publishes state updates
    back to the event stream

This isolates the domain logic from transport protocols and provides predictable execution paths.

Business Logic Layer (Processing Plane)​

This layer contains the core processing services, each responsible for a specific part of the transaction lifecycle.

Processor Types

  • Schema Validators – Validate XML/JSON messages against ISO 20022 schemas or internal models.
  • Enrichment Engines – Add debtor/creditor reference data, BIC derivation, risk scores, ledger data.
  • Transformation Services – Convert between pain → pacs → camt message families.
  • Lifecycle Managers – Maintain the transactional state machine (e.g., Initiated → Validated → Approved → Sent → Settled).
  • Compliance Engines – Screening, anomaly detection, limits, AML flags.

Processing Characteristics

  • Fully stateless, horizontally scalable
  • High-performance execution for payment bursts
  • Strict idempotency guarantees
  • Driven by immutable event logs for auditability

Integration Layer (External Connectivity)​

The Integration Layer provides protocol-specific connectors responsible for communication with external networks.

Supported Transports

  • MQ – ISO-based interbank rails, internal core banking systems
  • Kafka – streaming interfaces, real-time events, ingestion
  • SFTP – batch transfers (statements, reconciliation)
  • SWIFT / CBPR+ – global payments and correspondent banking
  • Domestic Clearing Rails – EuroSIC, SIC Inst, CERTIS, GIRO, etc.

Logical Role

Connectors handle:

  • Delivery guarantees (at-least-once / exactly-once)
  • Message signing/encryption (if required)
  • Gateway retry policies
  • Format conversion wrappers (XML envelopes, MT/MX mapping)

They abstract network behavior so upstream services operate on uniform message structures.

Shared Services Layer (Cross-Cutting Capabilities)​

This layer centralizes reusable capabilities that must remain consistent across all services.

Core Shared Modules

  • Audit Service – immutable transaction log, full traceability
  • Error Management – structured error schemas, retry strategies
  • Reference Data Service – BICs, country rules, scheme configs
  • Configuration Service – versioned, centralized runtime configs
  • Authentication & Authorization – user/service identity, token-based access
  • Logging & Monitoring – tracing, metrics, dashboards, structured logs
  • Notification System – email/SMS/webhook event triggers

By centralizing them, ImPAI standardizes behavior across microservices and eliminates duplicated code.

Customization & Configuration Layer (Adaptive Logic)​

The customization layer enables institutions to adapt processing logic dynamically without modifying code.

Configurable Elements

  • Routing rules (which orchestrator → which processor)
  • Transformation maps for ISO message structures
  • Business rules (limits, RBAC conditions, mandatory field sets)
  • Connector configurations (destination endpoints, credentials)
  • Behavioural flags per scheme, channel, client group

Operational Interface

A UI layer (planned) will allow operational staff to:

  • Adjust routing for new counterparties
  • Add new message validation rules
  • Modify field mappings
  • Enable/disable processing features per tenant

This allows rapid adaptation to regulatory changes and client-specific needs.

Execution Flow: End-to-End Transaction Example​

A typical SCT Inst payment moves through:

  1. API Gateway
    pain.001 received, authenticated, pre-validated
  2. Orchestrator
    determines scheme = SCT Inst → route to validation
  3. Validator Processor
    schema validation + business rule checks
  4. Enricher Processor
    add debtor/creditor metadata
  5. Lifecycle Manager
    transition to “Approval Pending”, “Processing”, etc.
  6. Transformer
    pain.001 → pacs.008 or pacs.004/camt.029
  7. Connector
    submit pacs.008 to clearing network
  8. Event Logger
    write audit entry + publish state change

Each step is isolated, horizontally scalable, and independently observable through metrics.

Summary (Technical Perspective)​

ImPAI’s architecture is designed for high-performance payment processing with:

  • Service isolation → fault tolerance
  • Microservice decomposition → independent scalability
  • Event-driven orchestration → deterministic processing
  • Flexible integration model → multi-scheme, multi-channel support
  • Strong auditability & compliance → immutable logs, consistent validation
  • Configurable behavior → meets varying institutional requirements

This provides a foundation capable of supporting modern instant payment systems with regulatory-grade reliability and operational transparency.