Neura

# Why it exists

Payment switches usually route transactions with static rules: round-robin, priority lists, a table someone updates by hand. Those rules don’t adapt to what is actually happening, whether that’s a bank going down, time-of-day patterns, or success rates that differ by card type.

Neura treats routing as a contextual bandit problem. For each transaction it looks at the context (card type, amount, time, merchant category, recent history) and picks the route most likely to succeed at the lowest cost, while still exploring enough to notice when conditions change.

# How it works

• Hexagonal core. neura-domain is free of frameworks. neura-infra holds the bank adapters (HTTP and ISO 8583), the AI router and the PostgreSQL ledger. neura-bootstrap wires it all together with Spring Boot.
• Learning loop. An epsilon-greedy policy with 5% exploration makes each decision. Outcomes flow through Kafka to a Python trainer, which exports an ONNX model that the Java service hot-reloads. A shadow mode compares its decisions against static routing before it takes over.
• Money handling. An append-only double-entry ledger in the LMAX style supports N-way marketplace splits.
• Resilience. Each bank gets its own circuit breaker, and 3-D Secure is applied based on risk.

# Design decisions

• Early Java on purpose. Java 26 value records from Project Valhalla reduce GC pressure on the hot path. Virtual threads handle I/O, and the Vector API speeds up inference.
• Training and serving kept apart. Models are trained in Python and served in Java through ONNX, so each side uses the best tool for its job.
• Stated targets, not claims. The design targets are sub-100 ms end-to-end latency and 10,000+ TPS on commodity hardware. They are goals, not benchmark results.

# Status

Maintained. Neura is a focused prototype, built to explore learned payment routing, and kept as a reference; it gets fixes rather than new features.