HYPERION‑X

What is Hyperion-X?

Hyperion-X is a production-grade financial payment switch designed to replace aging proprietary switch infrastructure with a modern, open-architecture platform. It routes and processes transactions across card networks (Visa, Mastercard, UnionPay), real-time rail systems (FedNow, SEPA Instant, PAPSS), and correspondent banking channels — all through a single, unified processing core.

The platform is built for financial institutions, banking-as-a-service operators, payment facilitators, and cross-border payment networks that need sub-100 ms authorization, cryptographic security to NIST standards, and verifiable compliance with PCI DSS v4.0.1, FAPI 2.0, and ISO 20022 CBPR+.

Target Markets

Core Value Proposition

Why Hyperion-X

Market Context

Global payment volumes are projected to reach $3.3 trillion transactions annually by 2027. Existing payment switch vendors (ACI, FIS, Temenos, Fiserv) charge per-transaction fees of $0.001–$0.005 on top of multi-million dollar license fees. A bank processing 500M transactions per year pays $500k–$2.5M annually in switch vendor fees alone — before customization, integration, or compliance uplift costs.

Key Business Drivers

Total Cost of Ownership Comparison

Two-Plane Architecture

Hyperion-X separates transaction processing concerns into a high-throughput data plane and a policy-aware control plane. This separation allows the data plane to be scaled and optimized independently — including replacement with a Rust hot-path for 50k TPS targets — while the control plane manages cryptography, policy, and compliance state.

Core Processing Components

Routing Architecture

The routing engine uses constrained optimization (shortest path with SLA and cost weights) over a multi-rail graph. BIN lookup uses a trie structure for O(log n) prefix matching. Fallback and override rules are applied in priority order before a final rail selection is committed.

Standards & Protocol Support

ISO 8583 — Card Transaction Messaging

Additional surfaces: PostBridge dialects, Zone XML field definitions, PIN block translation (ISO 9564 Formats 0/1/3/4), MAC verification (ISO 9797 Alg 3, HMAC-SHA256, AES-CMAC), private/MAC fields (DE 48, 63), and Rust parser fallback for high-throughput paths.

ISO 20022 — Real-Time & Correspondent Payments

EMV 3DS 2.3.1.1 — Strong Customer Authentication

Additional Rails & Schemes

Compliance Coverage

Hyperion-X ships with built-in compliance infrastructure — not just documentation. Evidence is collected programmatically and gated in CI, so compliance posture is continuously verified rather than point-in-time asserted.

Regulatory Reporting

Security

Post-Quantum Cryptography

Hyperion-X implements NIST-standardized post-quantum algorithms as a hybrid layer alongside classical cryptography — meaning no single cryptographic failure compromises the system.

HSM Architecture

A vendor-neutral HSM abstraction layer supports Thales payShield, Futurex KMES, and AWS CloudHSM through a unified interface — preventing vendor lock-in and enabling key ceremony standardization across hardware types.

Transport & Network Security

Identity & Access

Performance Characteristics

SLO Gate Matrix (CI-enforced)

Scalability Model

Throughput scales horizontally via stateless data-plane workers behind a load balancer. The system follows M/M/m queueing theory models for capacity planning: at target utilization ≤ 70%, average queue latency contribution is under 5 ms. The v1.1 Rust hot-path replaces the Python authorization core for 10× throughput improvement at equivalent infrastructure cost.

APIs & Integration

REST API (OpenAPI 3.1)

The primary integration surface is a versioned REST API at /v1/ with full OpenAPI specification. A SHA-256-pinned hyperion-public.yaml artifact is generated on every build — contract drift from the registered spec fails CI.

# Authorization endpoint
POST /v1/authorize
Authorization: DPoP {token}
Content-Type: application/json

{
  "payment_id": "01944abc-...",
  "tenant_id": "acq-ke-001",
  "amount_cents": 5000,
  "currency": "KES",
  "card_token": "tok_..."
}

gRPC / Protobuf

A gRPC service layer provides PaymentService and AccountService over HTTP/2 for inter-service communication. Bidirectional streaming enables real-time payment event subscriptions.

Webhooks

Guaranteed webhook delivery with 7-retry exponential backoff and HMAC-SHA256 signature verification. Dead-letter queue captures undeliverable events for replay. Delivery rate SLO: 99.9%.

Event Streaming

Server-Sent Events (SSE) at /v1/events/stream and Kafka topics for asynchronous event consumers. All events conform to CloudEvents v1.0 schema with typed schemas in configs/cloudevents/.

Multi-Language SDKs

Interactive API Playground

A built-in playground at /playground renders the OpenAPI spec with try-it-out capability using sandbox API keys — reducing integration friction for development teams.

Capability Matrix by Domain

Payment Processing

Card Issuing & Acquiring

Fraud & Risk

Identity & Onboarding

Financial Operations

Emerging & Specialty

Competitive Differentiation Table

Deployment Models

Infrastructure Requirements (Production Reference)

Testing & Formal Verification

Test Categories

TLA+ Formal Specifications (Selected)

Agency Banking Platform

Hyperion-X includes a fully integrated agency banking module that enables financial institutions to extend their reach through a network of human and automated agents — merchants, shops, mobile money operators — without opening physical branches. The module handles agent lifecycle, float management, liquidity distribution, transaction limits, and regulatory reporting under a single API surface.

Agent Network Management

Float & Liquidity Management

Float (e-money balance) is a liability on the institution's books. The platform manages float as a real-time sub-ledger entry within the main double-entry ledger, not as an external reconciliation batch.

Transaction Services via Agent Network

Commission & Revenue Engine

USSD & Channel Integration

Regulatory & Compliance

POS & Terminal Management

Hyperion-X manages the full lifecycle of POS terminal estates — from provisioning and key injection to transaction processing, settlement, and dispute initiation. The platform supports hardware POS (Ingenico, Verifone, PAX, Nexgo), SoftPOS (tap-on-phone), and browser-based virtual terminals, all routing through the same authorization core.

Terminal Lifecycle Management

EMV Card Acceptance

PIN Processing & Security

Offline & Intermittent Connectivity

Terminals in low-connectivity environments (rural agency banking, aircraft, remote retail) operate in offline authorization mode. The platform manages the associated risk through a configurable offline approval matrix.

Merchant Management

Virtual Terminal & eCommerce POS

Acquiring Settlement

POS Scheme Certification Coverage

Tokenization & Wallet Provisioning

Hyperion-X provides a dual-layer tokenization capability: a platform-native PAN vault for local token issuance, and certified integrations with Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) for network tokens accepted globally at any scheme-enabled merchant. Tokens are opaque 16-digit values that can be used wherever a PAN is accepted, isolating raw card data from every downstream system.

PAN Vault & Platform Tokens

Network Tokenization (VTS / MDES)

Network tokens are issued by card schemes directly and are accepted at any terminal worldwide without merchant integration changes. Hyperion-X acts as Token Requestor and manages the full provisioning and lifecycle on behalf of issuers and wallets.

Token Lifecycle State Machine

Digital Wallet Provisioning Flows

Dispute & Chargeback Lifecycle

Hyperion-X manages the full dispute lifecycle from cardholder claim through scheme arbitration — automating evidence assembly, deadline tracking, and scheme message generation (ISO 8583 0420/0430 and ISO 20022 pacs.004/camt.029) so operations teams are not manually keying into scheme portals.

Dispute Workflow

Chargeback Reason Codes

Automated Evidence Assembly

Chargeback Prevention

Network Architecture & Connectivity

Hyperion-X connects to card schemes, correspondent banking networks, and real-time rail systems through a layered connectivity stack. All external connections terminate at a dedicated DMZ gateway with strict egress filtering; no scheme connection traverses shared application network segments.

Scheme Connectivity Models

Network Segmentation

Latency Budget (POS Authorization)

Disaster Recovery & BCP Connectivity

Treasury, Liquidity & FX

Hyperion-X includes a real-time treasury module that manages intraday liquidity positions, nostro/vostro funding, FX conversion, and correspondent banking settlement — all as first-class ledger operations rather than batch reconciliation jobs.

Position Management

FX & Currency Conversion

Nostro / Vostro Account Management

Open Banking / PSD2 / FAPI 2.0

Hyperion-X implements a fully conformant Open Banking API surface aligned to the UK Open Banking Standard, EU PSD2 RTS on SCA, Berlin Group NextGenPSD2, and FAPI 2.0 security profile — enabling Third-Party Providers (TPPs) to initiate payments and access account information with robust consent governance.

TPP Roles Supported

Consent Lifecycle

FAPI 2.0 Security Profile

SCA & Exemptions

Fraud Detection & Risk Management

The fraud engine runs inline on the authorization hot-path and returns a score within 2–5 ms. It combines rule-based velocity checks, ML scoring, and graph analytics — each independently actionable or combined via a configurable decision policy.

Scoring Architecture

Feature Engineering (ML Model Inputs — Selected)

Model Governance

AML & Sanctions

Operations, Monitoring & Key Management

Observability Stack

Incident Severity Matrix

Key Management Operations

Backup & Recovery

Conceptual Data Model

Key entities and their relationships. All entities carry a UUID7 primary key, tenant_id for multi-tenant isolation, and created_at / updated_at timestamps. The ledger entities are append-only; no ledger record is ever updated in place.

Core Entities

Ledger Invariants (TLA+ proven)

Webhook & Event Catalog

All platform events conform to the CloudEvents v1.0 specification. Events are delivered via webhooks (HTTPS POST with HMAC-SHA256 X-Hyperion-Signature), Kafka topics, and the SSE stream at /v1/events/stream. Every event carries a UUID7 id, tenant_id, W3C traceparent, and monotonic sequence for gap detection.

Payment Events

Card & Token Events

Dispute & Settlement Events

Compliance & Risk Events

Webhook Delivery Guarantees

Migrating from a Legacy Payment Switch

Legacy switch migrations fail when they are treated as big-bang cutovers. Hyperion-X is designed for a phased, risk-minimized migration that runs the new and old systems in parallel until confidence is established.

Migration Phases

ISO 20022 CBPR+ Migration

Data Migration Checklist

Integration Prerequisites

Technical Glossary

Key terms used in this document and in conversations with Hyperion-X technical teams.

Payment Messaging

Cryptography & Security

Card & Transaction Processing

Settlement & Treasury

Compliance & Regulatory

Frequently Asked Questions

What programming language is Hyperion-X written in?

The v1.0 platform is Python 3.11+ throughout — async via asyncio, typed with Pydantic v2, served via FastAPI. The v1.1 Rust hot-path replaces the data-plane authorization core for 50k TPS targets while preserving the Python control plane.

How does it handle idempotency?

Every payment request carries a payment_id (UUID7). The idempotency gate acquires a distributed lock (Redis or PostgreSQL advisory lock) before processing; duplicate submissions within the TTL window return the cached result without re-processing. The TLA+ spec idempotency_protocol.tla formally proves no double-processing is possible.

What happens if the HSM fails?

The system fails closed, not open — authorizations requiring HSM-backed cryptography reject with a safe decline code rather than bypassing security. SIEM emits a critical alert. No PIN or key material is exposed in error responses. This behavior is CI-tested in test_hsm_failure.py (chaos scenario).

How is multi-tenancy enforced?

Every database query requires an explicit tenant_id parameter — enforced at the repository method signature level. Cross-tenant data access is prevented at the application layer, with PostgreSQL row-level security as a defence-in-depth backstop.

How does the platform scale horizontally?

Data-plane workers are stateless; they scale horizontally behind a load balancer. Session state (idempotency tokens, rate limit counters) lives in Redis. The ledger and settlement engine use PostgreSQL with read replicas. Kafka provides backpressure-managed buffering between ingress and processing tiers.

What is the migration path from a legacy ISO 8583 switch?

Hyperion-X supports a shadow-processing deployment where it receives a mirrored copy of live traffic, processes it, and logs discrepancies — without affecting production. Once confidence is established (typically 2–4 weeks), traffic is cut over. The built-in MT→MX converter and CBPR+ validator support parallel ISO 20022 migration.

Is the platform certified against Visa / Mastercard?

The platform ships a certification test harness covering Visa ADVT and Mastercard MPE test cases. Full scheme certification requires a formal engagement with each network; the harness significantly reduces the certification timeline by running the required test cases in-house before submission.

How is sensitive data handled (PAN, PIN, CVV)?

PANs are truncated/masked in all logs. PIN blocks are processed exclusively within HSM boundaries — the clear PIN never touches application memory. CVV2 values are verified and immediately discarded; never stored. PAN storage uses format-preserving encryption (FF3-1). All handling is gated by automated PCI DSS evidence tests.

What observability is included?

Prometheus metrics on every service (request count, latency histograms, error rates). OpenTelemetry distributed tracing with W3C traceparent propagation across all payment path hops. SIEM export in CEF format to Splunk HEC. SLA breach alerts in PagerDuty Events API v2 format. Grafana dashboards included.

What is the disaster recovery posture?

Multi-region active-active with CRDT state replication gives RPO = 0 for committed transactions. Geo-failover completes within 30 seconds (formally proven by geo_failover_fsm.tla). PostgreSQL hot standby provides HA within a single region. Backup snapshots to object storage every 15 minutes.